ES3026565T3 - Application-friendly protocol data unit (pdu) session management - Google Patents

Application-friendly protocol data unit (pdu) session management Download PDF

Info

Publication number
ES3026565T3
ES3026565T3 ES23220690T ES23220690T ES3026565T3 ES 3026565 T3 ES3026565 T3 ES 3026565T3 ES 23220690 T ES23220690 T ES 23220690T ES 23220690 T ES23220690 T ES 23220690T ES 3026565 T3 ES3026565 T3 ES 3026565T3
Authority
ES
Spain
Prior art keywords
application
smf
traffic
information
notification
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES23220690T
Other languages
English (en)
Inventor
Xu Li
Ngoc Dung Dao
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Application granted granted Critical
Publication of ES3026565T3 publication Critical patent/ES3026565T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W16/00—Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
    • H04W16/02—Resource partitioning among network components, e.g. reuse partitioning
    • H04W16/04—Traffic adaptive resource partitioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/14—Reselecting a network or an air interface
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/60—Subscription-based services using application servers or record carriers, e.g. SIM application toolkits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/04—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration using triggered events
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/53—Allocation or scheduling criteria for wireless resources based on regulatory allocation policies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/535—Allocation or scheduling criteria for wireless resources based on resource usage policies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/06—Registration at serving network Location Register, VLR or user mobility server
    • H04W8/065—Registration at serving network Location Register, VLR or user mobility server involving selection of the user mobility server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08—Upper layer protocols
    • H04W80/10—Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/12—Reselecting a serving backbone network switching or routing node
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/14—Reselecting a network or an air interface
    • H04W36/142—Reselecting a network or an air interface over the same radio air interface technology
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/16—Performing reselection for specific purposes
    • H04W36/22—Performing reselection for specific purposes for handling the traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H04W4/14—Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H04W8/14—Mobility data transfer between corresponding nodes

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Métodos mediante los cuales se intercambia información de gestión del plano de usuario (UP) entre una función de aplicación (AF) que soporta una o más aplicaciones y una función de gestión de segmentos (SMF) configurada para gestionar los flujos de tráfico en un segmento determinado de la red. El intercambio de información de gestión del UP puede iniciarse desde la AF o la SMF. En el caso del intercambio de información iniciado por la AF, la información de gestión del UP proporcionada por la AF puede incluir los requisitos de tráfico de las aplicaciones que soporta. En el caso del intercambio de información iniciado por la SMF, la información de gestión del UP proporcionada por la SM puede incluir información sobre políticas del operador o eventos, y la AF puede responder con información sobre los requisitos de tráfico de las aplicaciones que soporta. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Gestión de sesión de unidad de datos de protocolo (PDU) amigable con aplicaciones
CAMPO DE REALIZACIÓN DE LA INVENCIÓN
La presente invención atañe al campo de gestión de sesión de Unidad de Datos de Protocolo (PDU) en sistemas de conexión a red de comunicación y Gestión de Redes, y en particular a sistemas y métodos para gestión de sesión de PDU que permite el conocimiento de aplicaciones y gestión de sesión de Unidad de Datos de Protocolo (PDU) amigable con aplicaciones
ANTECEDENTES
El informe técnico del Proyecto de Asociación de 3a Generación (3GPP) numerado TR 23,799 y titulado "Study en Architecture para Next Generation System", versión 0.8.0, septiembre de 2016 (más adelante en esta memoria denominado TR 23,799), representa un planteamiento para el diseño de una arquitectura de sistema para red móvil de siguiente generación, también denominadas redes de 5a generación (5G). Como se propone en los documentos anteriores referenciados, la red se puede dividir lógicamente en un plano de control (CP) que soporta funcionalidad de control de red y un plano de usuario (UP) que soporta tráfico de datos que se comunica entre equipo de usuario (UE), servidores, y funciones de red disponibles en la red. En algunas realizaciones, también puede definirse un plano de gestión. Debe entenderse que los diferentes planos son construcciones lógicas. En muchos casos, los nodos y funciones dentro de la red pueden usar el mismo hardware físico y conexiones, aunque se consideran lógicamente distintos.
Las comunicaciones entre dispositivos conectados, tales como UE y servidores, son gestionadas por el CP. A diferencia de las redes de comunicación actuales, con sesiones de PDU de vida corta fija establecidas entre puntos finales, en redes de siguiente generación se propone a que sesiones de PDU puedan sostenerse durante periodos relativamente más largos durante los que los parámetros de sesión de PDU pueden tener que cambiarse.
Por lo tanto, existe la necesidad de un método y un aparato que den servicio a dispositivos de comunicación inalámbrica móvil en redes de comunicación inalámbrica tales como redes 5G propuestas, en las que las sesiones de PDU pueden al menos una de configurarse y actualizarse para reflejar parámetros de sesión de PDU actual tales como ubicación de sistema de aplicación o selección de UP.
La virtualización de funciones de red (NFV) es un concepto de arquitectura de red que usa las tecnologías de virtualización IT para crear clases enteras de funciones de red virtualizadas en bloques de edificios que se pueden conectar entre sí o a otras entidades, o pueden encadenarse juntas, para crear servicios de comunicación. NFV depende de técnicas tradicionales de virtualización de servidores, pero difiere de estas, tales como las usadas en IT empresarial. Una función de red virtualizada (VNF) puede consistir en una o más máquinas virtuales (VM) que ejecutan diferente software y procesos, encima de servidores estándar de gran volumen, conmutadores y dispositivos de almacenamiento, o incluso infraestructura computacional en la nube, en lugar de tener aparatos de hardware personalizados para cada función de red. En otras realizaciones, una VNF se puede proporcionar sin uso de una Máquina Virtual mediante el uso de otras técnicas de virtualización que incluyen el uso de contenedores. En realizaciones adicionales, un aparato de hardware personalizado puede ser residente dentro de la infraestructura física usada para diferentes redes virtuales, y puede presentarse a cada red virtual como versión virtual de sí misma en función de un particionado de los recursos del aparato entre redes. Por ejemplo, un controlador de frontera de sesión virtual podría inicializarse sobre recursos existentes para proteger un dominio de red sin el coste y la complejidad típicos de obtener e instalar unidades físicas de protección de red. Otros ejemplos de VNF incluyen equilibradores de carga virtualizados,<cortafuegos, dispositivos de detección de intrusiones y aceleradores de w>A<n>.
La estructura de NFV consiste en tres componentes principales:
Las funciones de red virtualizadas (VNF) son implementaciones de software de funciones de red que se pueden desplegar en una infraestructura de virtualización de funciones de red (NFVI).
La infraestructura de virtualización de funciones de red (NFVI) es la totalidad de todos componentes de hardware y software que proporcionan los recursos en los que se despliegan las VNF. La infraestructura de NFV puede abarcar varias ubicaciones. La red que proporciona conectividad entre estas ubicaciones se considera como parte de la infraestructura de NFV.
La estructura arquitectónica de gestión y orquestación de virtualización de funciones de red (MANO) (NFV-MANO Architectural Framework, por ejemplo la NFV-MANO definida por el Instituto Europeo de<Estándares en Telecomunicaciones>(E<t>SI),<denominado ETSI_MANO o ETSI NFV-MANO) es la>colección de todos bloques funcionales, repositorios de datos usados por estos bloques, y puntos de referencia e interfaces a través de los que estos bloques funcionales intercambian información con el propósito de gestionar y orquestar NFVI y VNF.
El bloque de construcción para ambos NFVI y la NFV-MANO son los recursos de una plataforma de NFV. Estos recursos pueden consistir en recursos de almacenamiento y procesamiento virtual y físico, software de virtualización y también pueden incluir recursos de conectividad tales como enlaces de comunicación entre los centros de datos o nodos que proporcionan los recursos físicos de procesamiento y almacenamiento. En su rol NFV-MANO la plataforma de n Fv consiste en gestores de VNF y NFVI y software de virtualización que funcionan en una plataforma de hardware. La plataforma de NFV se puede usar para implementar rasgos de grado de portador usados para gestionar y monitorizar los componentes de plataforma, recuperarse de fallos y proporcionar seguridad adecuada - todo requerido para la red de operadora pública.
La Topología Definida por Software (SDT) es una técnica de conexión a red que define una topología de red lógica en una red virtual. En función de requisitos del servicio proporcionado en la red virtual, y los recursos subyacentes disponibles, funciones virtuales y los enlaces lógicos que conectan las funciones se puede definir por un controlador de SDT, y esta topología puede entonces ejemplificarse para un caso de servicio de red dado. Por ejemplo, para un servicio de base de datos basado en la nube, una SDT puede comprender enlaces lógicos entre un cliente y uno o más casos de un servicio de base de datos. Como implica la nombre, una SDT típicamente será generada por un controlador de SDT que puede ser por sí mismo una entidad virtualizada en una red o segmento de red diferente. La determinación de topología lógica se hace por el controlador de SDT que genera un descriptor de Infraestructura de Servicio de Red (NSI) (NSLD) como salida. Puede usar una plantilla existente de un NSI y añadirle valores de parámetro para crear la NSLD, o puede crear una nueva plantilla y definir la composición de la NSI.
El Protocolo Definido por Software (SDP) es una técnica lógica de Extremo-a Extremo (E2E) que se puede usar dentro de un caso de servicio de red. SDP permite la generación de una pila de protocolos personalizados (que puede crearse usando un conjunto de bloques de construcción funcionales disponibles) que se puede proporcionar a diferentes nodos o funciones dentro de la red, o segmento de red. La definición de un protocolo específico de segmento puede tener como resultado diferentes nodos o funciones dentro de un segmento de red que tiene procedimientos definidos para llevar a cabo al recibir de un tipo de paquete. Como implica el nombre, un s Dp típicamente será generado por uno o más controladores de DP que puede ser funciones virtualizadas ejemplificas en un servidor.
La Adjudicación de Recursos Definida por Software (SDRA) se refiere al proceso de adjudicación de recursos de red para conexiones lógicas en la topología lógica asociada con un caso de servicio o segmento de red dado. En un entorno en el que los recursos físicos de una red se usan para soportar una pluralidad de segmentos de red, un controlador de SDRA adjudicará los recursos de procesamiento, almacenamiento y conectividad de la red a los diferentes segmentos de red para acomodar mejor lo acordado con requisitos de servicio para cada uno de los segmentos de red. Esto puede tener como resultado una adjudicación fija de recursos, o puede tener como resultado una adjudicación que se cambia dinámicamente para acomodar los diferentes requisitos temporales de procesamiento y distribución de tráfico. Como el nombre implica, un Controlador SDRA típicamente determinará una adjudicación de recursos, y puede implementarse como función que se inicializa sobre un servidor.
La Creación Automática de Red Orientada a Servicio (SONAC) es una tecnología que hace uso de topología definida por software (SDT), protocolo definido por software (SDP), y técnicas de adjudicación de recursos definidas por software (SDRA) para crear una red o red virtual para un caso de servicio de red dado. Al coordinar SDT, SDP, SDRA y en algunas realizaciones se puede obtener control, optimización y eficiencias adicionales de una Red Definida por Software (SDN). En algunos casos, se puede usar un controlador SONAC para crear un segmento de red dentro del que una red conforme al Proyecto de Asociación de 3a Generación (3GPP) se puede crear usando una infraestructura virtualizada (p. ej. VNF y enlaces lógicos) para proporcionar un servicio de Red Virtual (VN). Los expertos en la técnica apreciarán que los recursos adjudicados a los diferentes VNF y enlaces lógicos pueden ser controlados por la funcionalidad tipo SDRA de un controlador SONAC, mientras que la manera en la que las VNF se conectan se puede determinar por la funcionalidad tipo SDT del controlador SONAC. La manera en la que las VNF procesan paquetes de datos se puede definir por la funcionalidad tipo SDP del controlador SONAC. Un controlador SONa C se puede usar para optimizar la Gestión de Red, y así también puede considerarse que son un optimizador de Gestión de Red (NM).
Como detalla la implementación e implican los estándares de NFV, son sumamente deseables sistemas y métodos para asegurar que se pueden satisfacer acuerdos de nivel de servicio (SLA) de manera consistente y fiable.
Dentro de esta divulgación, abreviaturas que no se definen específicamente en esta memoria deben interpretarse según los Estándares típicos del Proyecto de Asociación de 3a Generación (3GPP), tales como, por ejemplo, Estándar Técnico TS 23.501 VO.3.1 (marzo de 2017).
El documento US2016156479 describe un método para proporcionar un servicio de patrocinio en un sistema de comunicación inalámbrica, el método comprende: determinar al menos un equipo de usuario (UE) al que proporcionar el servicio de patrocinio, acceder a un servidor que proporciona el servicio de patrocinio, y registra en el servidor que proporciona el servicio de patrocinio; y transmitir una petición del servicio de patrocinio que comprende información de identificación del al menos un UE, al servidor que proporciona el servicio de patrocinio.
Esta información de antecedentes se proporciona para revelar información que el solicitante cree que es de posible relevancia para la presente invención. No necesariamente se pretende admisión, ni se debe interpretar, que cualquier información anterior constituye técnica anterior contra la presente invención.
COMPENDIO
Un objeto de realizaciones de la presente invención es proporcionar sistemas y métodos para asegurar que se pueden satisfacer acuerdos de nivel de servicio (SLA).
En un primer aspecto de la presente invención, se proporciona un método para gestionar una notificación suscrita. El método comprende obtener, por una función de gestión de sesiones (SMF), información asociada con una selección de notificación de suscripción o reselección de plano de usuario (UP) de una función de aplicación (AF); y enviar, por parte de la SMF, una notificación de una selección o reselección de UP a la AF, la notificación comprende un tipo de notificación que indica que la notificación se envía antes o después configurarse un camino de UP.
En una realización del primer aspecto de la presente invención, la información de la AF indica el tipo de notificación. En otra realización, la notificación comprende una ubicación de aplicación.
En un segundo aspecto de la presente invención, se proporciona una función tal como una función de gestión de sesiones (SMF). La función comprende, un procesador y una memoria legible por ordenador. La memoria legible por ordenador almacena instrucciones que cuando son ejecutadas por el procesador hacen que la SMF se configure para obtener, de una Función de Aplicaciones (AF), información asociada con al menos una de una selección de notificación de suscripción de Plano de Usuario (UP) y una reselección de notificación de suscripción UP; y enviar, a través de la interfaz de red a la AF, una notificación de al menos una de una selección de UP y una reselección de UP, la notificación comprende un tipo de notificación que indica que la notificación se envía antes o después configurarse un camino de UP
En una realización del segundo aspecto de la presente invención, la información obtenida de la AF indica el tipo de notificación. En otra realización, la notificación comprende una ubicación de aplicación.
En un tercer aspecto de la presente invención, se proporciona un método para gestionar una notificación suscrita. El método comprende suscribirse, por una función de aplicación (AF), a una notificación acerca de una selección o reselección de plano de usuario (UP); y recibir, por la AF, un mensaje que comprende un tipo de notificación que indica que mensaje está antes o después configurarse un camino de UP, en donde el mensaje se asocia con la notificación acerca de la selección o reselección de UP
En una realización del tercer aspecto, suscribirse a la notificación comprende enviar una petición para suscribirse a la notificación, la petición comprende el tipo de notificación. En otra realización, el mensaje incluye una ubicación de aplicación.
En un cuarto aspecto de la presente invención, se proporciona una función de red tal como una Función de Aplicaciones (AF). La función de red comprende, un procesador y una memoria legible por ordenador. La memoria legible por ordenador almacena instrucciones que cuando son ejecutadas por el procesador hacen que la función de red se configure para suscribirse a una notificación acerca de al menos uno de una selección de plano de usuario (UP) y una reselección de UP; y recibir un mensaje que comprende un tipo de notificación que indica que el mensaje es antes o después configurarse un camino de UP, en donde el mensaje se asocia con la notificación acerca de la selección o reselección de UP
En una realización del cuarto aspecto de la presente invención, la memoria legible por ordenador almacena instrucciones que cuando son ejecutadas por el procesador además hacen que la AF se configure para suscribirse a la notificación al enviar una petición para suscribirse a la notificación, la petición comprende el tipo de notificación. En otra realización, el mensaje recibido comprende una ubicación de aplicación.
Los expertos en la técnica apreciarán que las realizaciones descritas anteriormente se pueden implementar juntamente con la realización con la que se han descrito, y pueden implementarse conjuntamente con otras realizaciones del aspecto con el que se han descrito. En algunos casos, una realización puede implementarse juntamente con aspectos complementarios incluso si no se describe explícitamente como que es aplicable anteriormente.
Por consiguiente, un aspecto de la presente invención proporciona un método por la información de gestión de Plano de Usuario (UP) se intercambia entre una Función de Aplicaciones (AF) que soporta una o más aplicaciones y una función de gestión de segmentos (SMF) configurada para gestionar flujos de tráfico en un segmento dado de la red.
En una implementación, se proporciona un método para gestionar tráfico de datos de sesión de unidad de datos de protocolo en una red, el método comprende una entidad de plano de control disponible en la red: recibir una notificación de ubicación de Sistema de Aplicación (AS) basada en interfaz de programa de aplicación (API) de un controlador de AS, la notificación de ubicación de AS basada en API identifica una ubicación de AS y tráfico de datos a asociar con la ubicación de AS identificada; y, transmitir una notificación de ubicación de As para ubicar la AS.
En una implementación, antes de que la entidad de plano de control transmite la notificación de ubicación de AS, donde el método comprende además la entidad de plano de control que autentica el controlador de AS. Autenticar el controlador de AS puede comprender transmitir una petición de autenticación a una función de servidor de autenticación (AUSF) disponible en la red; y, recibir una respuesta de autenticación de la AUSF que indica un resultado de autenticación en respuesta a la petición de autenticación.
En una implementación, la notificación de ubicación de AS comprende una notificación de reubicación de AS que cambia una ubicación existente de una sesión de PDU.
En una implementación, en donde la notificación de ubicación de AS comprende una notificación de ubicación de AS que establece una ubicación de una sesión de PDU futura. La notificación de reubicación de AS puede transmitirse a una función de gestión de sesiones (SMF) para configurar direccionamiento de tráfico para el tráfico de datos al AS reubicado.
En una implementación, la notificación de ubicación de AS se transmite a una Función de Control de Políticas (PCF) para generar una política de selección de plano de usuario (UP) y política de direccionamiento de tráfico para el tráfico de datos.
En una implementación, se proporciona un método para gestionar tráfico de datos de sesión de unidad de datos de protocolo (PDU) intercambiado con un equipo de usuario (UE) conectado a una red, el método comprende una entidad de plano de control disponible en la red: recibir una petición de sesión de PDU del UE; verificar el contexto de UE y autorizar la petición de sesión en función de datos de suscripción de usuario, y si se autoriza el método comprende además: seleccionar y establecer un camino de plano de usuario (UP) para la sesión de PDU pedida; transmitir una respuesta de petición de sesión de PDU al UE.
En una implementación, la petición de sesión de PDU incluye un ID de sesión.
En una implementación, la petición de sesión de PDU incluye un modo de SSC preferido para la sesión de PDU pedida.
En una implementación, la petición de sesión de PDU incluye un identificador de aplicación que indica que la petición de sesión de PDU se dedica a una aplicación asociada con el identificador de aplicación.
BREVE DESCRIPCIÓN DE LAS FIGURAS
Características y ventajas adicionales de la presente invención resultan evidentes a partir de la siguiente descripción detallada, tomada en combinación con los dibujos adjunto, en los que:
La FIG. 1 es un diagrama de bloques de un sistema informático 100 que se puede usar para implementar dispositivos y métodos según las realizaciones representativas de la presente invención;
la FIG. 2 es un diagrama de bloques que ilustra esquemáticamente una arquitectura de un servidor representativo utilizable en realizaciones de la presente invención;
la FIG. 3A es un diagrama de bloques que ilustra una vista basada en servicio de una arquitectura de sistema de una Red Central 5G;
la FIG. 3B ilustra una realización de un controlador de Sistema de Aplicación responsable de ubicar, reubicar, seleccionar o reseleccionar un AS dentro de una red de AS;
la FIG. 4. es un diagrama de bloques que ilustra esquemáticamente reubicación de aplicación, la FIG. 5, presenta un diagrama de señalización que ilustra una realización de notificación de ubicación o reubicación de AS,
la FIG. 6 presenta un diagrama de señalización que ilustra una realización de un procedimiento de petición de notificación de (re)selección de UP,
la FIG. 7 presenta un diagrama de señalización que ilustra una realización de un procedimiento de notificación de (re)selección de UP,
la FIG. 8 presenta un diagrama de señalización que ilustra una realización de un procedimiento para un establecimiento de sesión de PDU amigable con aplicación,
la FIG. 9 presenta un diagrama de señalización que ilustra una realización de un procedimiento de reselección de UP amigable con aplicación para modificación de sesión de PDU.
la FIG. 10 es un diagrama de bloques que ilustra una realización de una arquitectura de red, las FIGs. 11A y 11B son diagramas de señalización que ilustran una realización de selección de UP influenciada por aplicación realizada por la SMF como parte de establecimiento de sesión,<las FIGs. 12A y 1>2<b son diagramas de señalización que ilustran realizaciones de un procedimiento de>reselección de UP influenciado por aplicación,
la FIG. 13 es un diagrama de señalización que ilustra una realización de procedimiento de servicio de notificación de (re)ubicación de aplicación,
la FIG. 14 es un diagrama de señalización que ilustra una realización de un Servicio de Notificación de (re)selección de UP,
la FIG. 15 es un diagrama de bloques que ilustra relaciones entre Funciones de Plano de Usuario, Identificadores de Acceso Dinámico a Red y el hospedaje de aplicaciones para indicar la selección (posiblemente) implícita de un función de plano de usuario resultante de la selección de una Red Dinámica,
la FIG. 16 es un diagrama de señalización que ilustra una realización de un procedimiento de notificación de (re)selección de UP,
la FIG. 17 es un diagrama de señalización que ilustra una realización de un procedimiento para<Establecimiento de Sesión de PDU pedida por>U<e para no-itinerancia e itinerancia con ruptura local,>las FIGs. 18A y 8B muestran un diagrama de señalización que ilustra una realización de un reconfiguración de anclaje de sesión de PDU debido a reubicación de aplicación,
la FIG. 19 es un diagrama de señalización que ilustra una realización de un método para reubicación de anclaje de sesión de PDU para una sesión de PDU dedicada a una aplicación de Computación en el Borde,
la FIG. 20 es un diagrama de señalización que ilustra una realización de un método para reubicación de anclaje de sesión de PDU para una sesión de PDU compartida por múltiples aplicaciones de Computación en el Borde,
la FIG. 21 es un diagrama de red simplificado que ilustra una realización de gestión segmentada, la FIG. 22 es un diagrama de red simplificado que ilustra gestión segmentada según realizaciones de la presente invención;
la FIG. 23 es un diagrama de flujo de llamada que ilustra respectivos procesos de ejemplo según realizaciones de la presente invención;
la FIG. 24 es un diagrama de flujo de llamada que ilustra respectivos procesos de ejemplo según realizaciones de la presente invención;
las FIGs. 25A - 25C son diagramas de flujo de llamada que ilustra respectivos procesos de ejemplo según realizaciones de la presente invención;
la FIG. 26 es un diagramas de flujo de llamada que ilustra un proceso de ejemplo adicional según realizaciones de la presente invención;
las FIGs. 27A y 27B muestran diagramas de flujo de llamada que ilustran respectivos procesos para notificación de gestión de camino de UP a una AF según realizaciones de ejemplo de la presente invención; y
las FIGs. 28A y 28B muestran un diagrama de flujo de llamada que ilustra un proceso alternativo para<notificación de gestión de camino de UP a una>A<f según una realización de ejemplo de la presente>invención;
las FIGs. 29A y 29B muestran un diagrama de flujo de llamada que ilustra un proceso alternativo<adicional para notificación de gestión de camino de>U<p a una AF según una realización de ejemplo de>la presente invención;
la FIG. 30 es un diagrama de flujo que ilustra un proceso según una realización de ejemplo de la presente invención; y
la FIG. 31 es un diagrama de bloques lógico que ilustra una relación de ejemplo entre ubicación de aplicación, DNAI y UPF, según realizaciones de la presente invención.
Se señalará que por todos los dibujos adjuntos, rasgos semejantes se identifican con numerales de referencia semejantes.
DESCRIPCIÓN DETALLADA
Dentro de esta solicitud, el término dirección IP se ha usado en las realizaciones ejemplares. Debe entenderse que en diferentes realizaciones, diferentes identificadores y direcciones tales como una dirección de hardware, una dirección IP, una dirección MAC, u otra dirección a se puede usar en lugar de la dirección IP cuando sea aplicable.
La FIG. 1 es un diagrama de bloques de un sistema informático 100 que se puede usar para implementar los dispositivos y métodos descritos en esta memoria. Dispositivos específicos pueden utilizar todos los componentes mostrados o únicamente un subconjunto de los componentes, y los niveles de integración pueden variar de un dispositivo a otro. Es más, un dispositivo puede contener múltiples casos de un componente, tales como múltiples unidades de procesamiento, procesadores, memorias, transmisores, receptores, etc. El sistema informático 100 incluye una unidad de procesamiento 102. La unidad de procesamiento 102 también se puede denominar Dispositivo Electrónico (ED). En algunas realizaciones, la unidad de procesamiento 102 puede ser un equipo de usuario (UE), mientras que en otras realizaciones puede ser una plataforma de computación tal como un servidor de computación dentro de un entorno de centro de datos. La unidad de procesamiento 102 incluye típicamente una unidad de procesamiento central (CPU) 114, un bus 120 y una memoria 108, y puede incluir además opcionalmente un dispositivo de almacenamiento masivo 104, un adaptador de vídeo 110, y una interfaz de E/S 112 (mostrados en líneas discontinuas). Los expertos en la técnica apreciarán que la CPU 114 es representativa de una capacidad de procesamiento. En algunas realizaciones, en lugar de una CPU convencional, se puede proporcionar un núcleo de procesamiento especializado. Por ejemplo, una Unidad de Procesamiento de Gráficos (GPU) u otros procesadores acelerados denominados (o aceleradores de procesamiento) se pueden proporcionar además o en lugar de la CPU.
La CPU 114 puede comprender cualquier tipo de procesador electrónico de datos. La memoria 108 puede comprender cualquier tipo de memoria de sistema no transitoria tal como memoria de acceso aleatorio estática (SRAM), memoria de acceso aleatorio dinámica (DRAM), DRAM sincrónica (SDRAM), memoria de solo lectura (ROM), o una combinación de las mismas. En una realización, la memoria 108 puede incluir ROM para su utilización en el arranque, y DRAM para almacenamiento de programas y datos para su utilización mientras se ejecutan programas. El bus 120 puede ser uno o más de cualquier tipo de varias arquitecturas de bus que incluyen un bus de memoria o controlador de memoria, un bus de periféricos, o un bus de vídeo.
El almacenamiento masivo 104 puede comprender cualquier tipo de dispositivo de almacenamiento no transitorio configurado para almacenar datos, programas y otra información y para hacer los datos, programas y otra información accesibles por medio del bus 120. El almacenamiento masivo 104 puede comprender, por ejemplo, una o más de una unidad de estado sólido, una unidad de disco duro, una unidad de disco magnético o una unidad de disco óptico.
El adaptador de vídeo 110 y la interfaz de E/S 112 proporcionan interfaces opcionales para acoplar dispositivos externos de entrada y salida a la unidad de procesamiento 102. Ejemplos de dispositivos de entrada y salida incluyen una pantalla 118 acoplada al adaptador de vídeo 110 y un dispositivo de E/S 116, tal como una pantalla táctil acoplada a la interfaz de E/S 112. Otros dispositivos pueden acoplarse a la unidad de procesamiento 102, y se pueden utilizar interfaces adicionales o menos. Por ejemplo, se puede usar una interfaz serie tal como bus serie universal (USB) (no se muestra) para proporcionar una interfaz para un dispositivo externo.
La unidad de procesamiento 102 también puede incluir una o más interfaces de red 106, que puede comprender al menos uno de enlaces cableados, tal como un cable Ethernet y enlaces inalámbricos para acceder a una o más redes 122. Las interfaces de red 106 permiten a la unidad de procesamiento 102 comunicar con unidades remotas por medio de las redes 122. Por ejemplo, las interfaces de red 106 pueden proporcionar comunicación inalámbrica por medio de uno o más transmisores/antenas de transmisión y uno o más receptores/antenas de recepción. En una realización, la unidad de procesamiento 102 se acopla a una red de área local o una red de área ancha para procesamiento de datos y comunicaciones con dispositivos remotos, tales como otras unidades de procesamiento, internet, o instalaciones de almacenamiento remoto.
La FIG. 2 es un diagrama de bloques que ilustra esquemáticamente una arquitectura de un servidor representativo 200 utilizable en realizaciones de la presente invención. Se contempla que el servidor 200 pueda implementarse físicamente como uno o más ordenadores, dispositivos de almacenamiento y rúters (cualquier o todos de ellos se pueden construir según el sistema 100 descrito anteriormente con referencia a la FIG. 1) interconectados juntos para formar una red local o agrupación, y que ejecutan software adecuado para realizar sus funciones pretendidas. Los expertos identificarán que hay muchas combinaciones adecuadas de hardware y software que se pueden usar para las finalidades de la presente invención, que son conocidas en la técnica o pueden desarrollarse en el futuro. Por esta razón, una figura que muestra el hardware físico de servidor no se incluye en esta memoria descriptiva. En cambio, el diagrama de bloques de la FIG. 2A muestra una arquitectura de funcional representativa de un servidor 200, se entiende que esta arquitectura de funcional puede implementarse usando cualquier combinación adecuada de hardware y software.
Como puede verse en la FIG. 2, el servidor 200 ilustrado generalmente comprende una infraestructura de hospedaje 202 y una plataforma de aplicaciones 204. La infraestructura de hospedaje 202 comprende los recursos de hardware físico 206 (tales como, por ejemplo, recursos procesamiento de información, reenvío de tráfico y almacenamiento de datos) del servidor 200, y una capa de virtualización 208 que presenta una abstracción de los recursos de hardware 206 a la plataforma de aplicaciones 204. Los detalles específicos de esta abstracción dependerán de los requisitos de las aplicaciones hospedadas por la capa de Aplicaciones (descrita más adelante). Así, por ejemplo, una aplicación que proporciona funciones de reenvío de tráfico puede presentarse con una abstracción de los recursos de hardware 206 que simplifica la implementación de políticas de reenvío de tráfico en uno o más rúters. De manera similar, una aplicación que proporciona funciones de almacenamiento de datos puede presentarse con una abstracción de los recursos de hardware 206 que facilita el almacenamiento y la recuperación de datos (por ejemplo usando Protocolo de Acceso de Directorio Ligero -LDAP).
La plataforma de aplicaciones 204 proporciona las capacidades para hospedar aplicaciones e incluye un gestor de virtualización 210 y servicios de plataforma de aplicaciones 212. El gestor de virtualización 210 soporta un entorno de hospedaje y tiempo de ejecución multipropiedad eficiente y flexible para aplicaciones 214 al proporcionar instalaciones de Infraestructura como Servicio (IaaS). En funcionamiento, el gestor de virtualización 210 puede proporcionar un "sandbox" (zona segura) de recursos y seguridad para cada aplicación hospedada por la plataforma 204. Cada "sandbox" puede implementarse como Máquina Virtual (VM) 216, o como contenedor virtualizado, que puede incluir un sistema operativo apropiado y acceso controlado a recursos de hardware (virtualizados) 206 del servidor 200. Los servicios de plataforma de aplicaciones 212 proporcionan un conjunto de servicios de aplicaciones middleware y servicios de infraestructuras a las aplicaciones 214 hospedados en la plataforma de aplicaciones 204, como se describirá con mayor detalle más adelante.
Las aplicaciones 214 de vendedores, proveedores de servicios y terceros pueden desplegarse y ejecutarse o dentro de una Máquina Virtual 216 respectiva. Por ejemplo, MANO y SONAC (y su diversas funciones tales como SDT, SDP y SDRA) pueden implementarse por medio de una o más aplicaciones 214 hospedadas en la plataforma de aplicaciones 204 como se ha descrito anteriormente. La comunicación entre aplicaciones 214 y servicios en el servidor 200 puede diseñarse convenientemente según los principios de Arquitectura Orientada a Servicios (SOA) conocida en la técnica.
Los servicios de comunicación 218 pueden permitir a las aplicaciones 214 hospedadas en un único servidor 200 comunicar con los servicios de plataforma de aplicaciones 212 (a través de Interfaces de Programación de Aplicaciones (API) predefinidas por ejemplo) y entre sí (por ejemplo a través de un API específica de servicio).
Un registro de Servicio 220 puede proporcionar visibilidad de los servicios disponibles en el servidor 200. Adicionalmente, el registro de servicio 220 puede presentar disponibilidad de servicios (p. ej. estado del servicio) junto con las interfaces y versiones relacionadas. Esto puede ser usado por aplicaciones 214 para descubrir y localizar los puntos finales para los servicios que ellas requieren, y para publicar su propio punto final de servicio para que otras aplicaciones lo usen.
La computación en el borde móvil permite a los servicios de aplicaciones en la nube hospedarse junto con elementos de red móvil, y también facilita el aprovechamiento de la información disponible de radio y red en tiempo real disponible. Los Servicios de Información de Red (NIS) 222 pueden proporcionar a las aplicaciones 214 con información de red de bajo nivel. Por ejemplo, la información proporcionada por NIS 222 puede ser usada por una aplicación 214 para calcular y presentar datos de alto-nivel y significativos tales como: ID de celda, ubicación del abonado, carga de celda y orientación de rendimiento.
Un servicio de Función de Tráfico sin Carga (TOF) 224 puede priorizar el tráfico y flujos de datos usuario seleccionados por ruta, basados en políticas, hacia y desde aplicaciones 214. El servicio TOF 224 puede suministrarse a aplicaciones 224 de diversas maneras, que incluye: Un modo de paso a través donde tráfico (al menos uno de enlace ascendente y enlace descendente) se pasa a una aplicación 214 que puede monitorizar, modificar o formar y entonces enviarse de regreso a la conexión original de Red de Datos de Paquete (PDN) (p. ej. portadora 3GPP), y un modo de punto final, donde el tráfico es terminado por la aplicación 214 que actúa como servidor.
La FIG. 3A ilustra una arquitectura basada en servicio 300 para una Red Central de siguiente generación o 5G (5GCN / NGCN/ NCN). Esta ilustración representa conexiones lógicas entre nodos y funciones, y sus conexiones ilustradas no deben interpretarse como conexiones físicas directas. Una ED 102 forma una conexión de red de acceso por radio con un nodo de Red de Acceso (Por Radio) ((R)AN) 302 (que puede, por ejemplo, ser un gNodeB (gNB)), que se conecta a una función de Plano de Usuario (UP) (UPF) 304 tal como una Pasarela de UP en una interfaz de red que proporciona una interfaz definida tal como una interfaz N3. La UPF 304 proporciona una conexión lógica a una red de datos (DN) 306 en una interfaz de red tal como una interfaz n 6. La conexión de red de acceso por radio entre el ED 102 y el nodo de (R)AN 302 puede denominarse Portador de Radio de Datos (DRB).
La DN 306 puede ser una red de datos usada para proporcionar un servicio de operadora, o puede estar fuera del alcance de la estandarización del Proyecto de Asociación de Tercera Generación (3GPP), tal como internet, una red usada para proporcionar servicio de terceros, y en algunas realizaciones DN 306 puede representar un recurso o red de cálculo de vanguardia, tal como una red de computación en el borde Móvil (MEC).
El ED 102 también se conecta a la Función de Gestión de Acceso y Movilidad (AMF) 308 a través de una conexión N1 lógica (aunque el camino físico de la conexión no es directo). La AMF 308 es responsable de autenticación y autorización de solicitudes de acceso, así como funciones de gestión de movilidad. La AMF 308 puede realizar otros roles y funciones definidas por la Especificación Técnica 3GPP (TS) 23.501. En una vista basada en servicio, AMF 308 puede comunicar con otras de funciones de plano de control de red central a través de una interfaz basada en servicio denotada Namf.
La Función de Gestión de Sesiones (SMF) 310 es una función de red que es responsable de la adjudicación y gestión de direcciones IP que se asignan a un ED así como la selección de una UPF 304 (o un caso particular de una UPF 304) para tráfico asociado con una sesión de ED 102 particular. Se apreciará que típicamente habrá múltiples SMF 310 en la red 300, cada una de las cuales puede asociarse con un respectivo grupo de ED 102, nodos de (R)AN 302 o UPF 304. La SMF 310 puede comunicar con otras funciones de red central, en una vista basada en servicio, a través de una interfaz basada en servicio denotada Nsmf. La SMF 310 también pueden conectarse a una UPF 304 a través de una interfaz lógica tal como interfaz de red N4.
La Función de Servidor de Autenticación (AUSF) 312, proporciona servicios de autenticación a otras funciones de red sobre una interfaz basada en servicio Nausf.
Una función de Exposición de Red (NEF) 314 se puede desplegar en la red para permitir servidores, funciones y otras entidades tales como las exteriores a un dominio de confianza para tener exposición a servicios y capacidades dentro de la red. En tal ejemplo, una NEF 314 puede actuar como proxy entre un servidor de aplicaciones fuera de la red ilustrada y funciones de red tal como la Función de Control de Políticas (PCF) 314, la SMF 310, la UDM 320 y la AMF 308, de modo que el servidor de aplicaciones externo puede proporcionar información que puede ser de uso en la preparación de los parámetros asociados con una sesión de datos. La NEF 314 puede comunicar con otras funciones de red a través de una interfaz de red basada en servicio Nnef. La NEF 314 también puede tener una interfaz con funciones no 3GPP.
Una Función de Repositorio de Red (NRF) 318, proporciona funcionalidad de descubrimiento de servicio de red. La NRF 318 puede ser específica para la Red de Movilidad Terrestre Pública (PLMN) u operadora de red, con la que se asocia. La funcionalidad de descubrimiento de servicio puede permitir funciones de red y ED conectadas a la red para determinar dónde y cómo acceder a funciones de red existentes, y puede presentar la interfaz basada en servicio Nnrf.
La PCF 314 se comunica con otras funciones de red por una interfaz basada en servicio Npcf, y se puede usar para proporcionar política y reglas a otras funciones de red, que incluye aquellas dentro del plano de control. El refuerzo y la aplicación de las políticas y reglas no es necesariamente responsabilidad de la PCF 314, y en cambio típicamente es responsabilidad de las funciones a las que la PCF 314 transmite la política. En tal ejemplo la PCF 314 puede transmitir política asociada con gestión de sesiones a la SMF 310. Esto se puede usar para permitir una estructura de políticas unificada con la que se puede controlar el comportamiento de red.
Una Función de Gestión Unificada de Datos (UDM) 320 puede presentar una interfaz basada en servicio Nudm para comunicarse con otras funciones de red, y puede proporcionar instalaciones de almacenamiento de datos a otras funciones de red. El almacenamiento de datos unificado puede permitir una vista consolidada de información de red que se puede usar para asegurar que la mayor parte de información relevante se puede hacer disponible a diferentes funciones de red desde un único recurso. Esto puede hacer más fácil la implementación de otras funciones de red, ya que no necesita determinar dónde se almacena un tipo particular de datos en la red. La UDM 320 puede emplear una interfaz, tal como Nudr para conectarse a un Repositorio de Datos de Usuario (UDR) 322. La PCF 314 puede asociarse con la UDM 320 porque puede implicarse con solicitar y proporcionar información de política de suscripción al UDR, pero debe entenderse que típicamente la PCF 314 y la UDM 320 son funciones independientes.
La PCF 314 puede tener una interfaz directa al UDR 322 o puede usar interfaz Nudr para conectar con UDR 322. La UDM 320 puede recibir solicitudes para recuperar contenido almacenado en el UDR 322, o solicitudes para almacenar contenido en el UDR 322. La UDM 320 es típicamente responsable de funcionalidad tal como el procesamiento de credenciales, gestión de ubicación y gestión de suscripción. El UDR 322 también pueden soportar cualquiera o todos de Procesamiento de Credenciales de Autenticación, Manejo de Identificación de Usuarios, Autorización de Acceso, gestión de registro/movilidad, gestión de suscripción y gestión de Servicio de Mensajes Cortos (SMS). El UDR 322 es típicamente responsable de almacenar datos proporcionados por la UDM 320. Los datos almacenados se asocian típicamente con información de perfil de política (que pueden ser proporcionadas por la PCF 314) que controla los derechos de acceso a los datos almacenados. En algunas realizaciones, el UDR 322 puede almacenar datos de política, así como datos de suscripción de usuario que pueden incluir cualquiera o todos los identificadores de suscripción, credenciales de seguridad, acceso y datos de suscripción relacionados con movilidad y datos relacionados con sesión.
La Función de Aplicaciones (AF) 324 representa la funcionalidad de plano no de datos (también denominado el plano no de usuario) de una aplicación desplegada dentro de un dominio de operadora de red y dentro de una red conforme con 3GPP. La A<f>324 interactúa con otras funciones de red central a través de una interfaz basada en servicio Naf, y puede acceder a información de exposición de capacidad de red, así como proporcionar información de aplicación para usar en decisiones tales como enrutamiento de tráfico. La AF 324 puede también interactuar con funciones tales como la PCF 314 para proporcionar entrada específica de aplicación a política y decisiones de refuerzo de políticas. Debe entenderse que en muchas situaciones la AF 324 no proporciona servicios de red a otras NF, y en cambio a menudo se ve como consumidor o usuario de servicios proporcionados por otras NF. Una aplicación fuera de la red 3GPP, puede realizar muchas de las mismas funciones que AF 324 mediante el uso de NEF 314.
El ED 102 comunica con funciones de red que están en el plano de Usuario (UP) 326, y el plano de control (CP) 328. La UPF 304 es una parte del UP de CN 326 (DN 306 está fuera de la 5GCN). El nodo (R)AN 302 puede considerarse como parte de un Plano de Usuario, pero como no es estrictamente una parte de la CN, no se considera que sea una parte del UP de CN 326. AMF 308, SMF 310, AUSF 312, NEF 314, NRF 318, PCF 314 y UDM 320 son funciones que residen dentro del CP de CN 328, y a menudo se denominan Funciones de Plano de Control. La AF 324 puede comunicar con otras funciones dentro de CN CP 328 (ya sea directa o indirectamente a través de la NEF 314), pero típicamente no se considera que sea una parte del CP de CN 328.
Los expertos en la técnica apreciarán que puede haber una pluralidad de UPF conectadas en serie entre el nodo (R)AN 302 y la DN 306, y múltiples sesiones de datos a diferentes DN se pueden acomodar mediante el uso de múltiples UPF en paralelo.
La FIG. 3B ilustra una parte de la red de comunicación inalámbrica 300 en la que el UE 102 se conecta al plano de control (CP) de Red Central (CN) 328 y al Plano de Usuario (UP) de CN 326 por medio del Nodo de Acceso<(AN) 302.>C<n>C<p 328 incluye la función de Gestión Unificada de Datos (UDM) 320, que comunica con el Plano>de Gestión 330.
Un controlador de Sistema de Aplicación (AS) 332 es responsable de ubicar, reubicar, seleccionar o reseleccionar un AS dentro de una red de AS 334. El controlador de AS 332 se conecta al CP de CN 328 a través de la Función de Exposición de Red (NEF) 314.
El CP de CN 328 puede funcionar para gestionar la ubicación lógica de recursos dentro del dominio de 3GPP. Un Servidor de Aplicaciones o Sistema de Aplicación de la red de AS 334 es gestionado por el controlador de AS 332. La capacidad de direccionamiento de tráfico o calidad de interconexión (p. ej. medida por rendimiento, retraso, carga tales como sesiones de PDU), entre el UP de CN 326 y el AS se proporciona al CP de CN 328 por funciones de red dentro del plano de gestión 330 e información asociada con estas capacidades y parámetros de calidad de conexión se puede almacenar en la UDM 320. La información de capacidad de direccionamiento de tráfico puede ser usada por el CP 328 para establecer un camino eficiente de extremo a extremo entre partes que se comunican.
El CP de CN 328 comunica con un UE 102 conectado a través de una interfaz NG1, y a la AN 302 que proporciona conectividad a través de la interfaz NG2. La AN 302 comunica con el UP de CN 326 a través de la interfaz NG3. El UP de CN 326 es controlado por el CP de CN 328 a través de la interfaz NG4. Las interfaces NG1, NG2, NG3 y NG4 se describen más en detalle, y se definen por los estándares de banda ancha móvil 3GPP. Los expertos en la técnica apreciarán que se pueden hacer variaciones a la definición específica de estas interfaces sin apartarse de la invención descrita en esta memoria. Términos específicos de definición de estas interfaces se pueden encontrar en documentos públicamente accesibles (ver, por ejemplo, www.3gpp.org documentos históricos y actuales de estándares).
El CP de CN 328 es responsable de configurar direccionamiento de tráfico en la Pasarela de Plano de Usuario (UP) (GW) 336 para tráfico de aplicaciones de enlace ascendente (UL) de enrutamiento a la ubicación de AS apropiado, posiblemente teniendo en cuenta posible (re)ubicación de AS intrasesión.
La red de AS 334 es responsable de direccionar tráfico de aplicaciones de enlace descendente (DL) al UP GW 336 apropiado posiblemente teniendo en cuenta posible (re)selección de UP intrasesión.
El direccionamiento de tráfico conducido por la red de AS 334 puede ser configurado por el controlador de AS 332. En algunas realizaciones, el direccionamiento de tráfico conducido por la red de AS 334 puede ser configurado por, o realizado a través de, mecanismos de gestión de movilidad de nivel superior dentro de la propia red de AS 334. En el ejemplo de la FIG. 3B, la línea que conecta el UP GW 336 a la red de AS 334 indica un enlazamiento que conecta el UP de CN 326 a la red de AS 334 que se realiza a través de direccionamiento de tráfico. Los siguientes diagramas de señalización en esta solicitud describen implementaciones que se enfocan en la interacción entre el UP de CN 326 y la red de AS 334 para permitir gestión de sesión consciente de aplicación de PDU para tráfico de aplicaciones usando un camino eficiente de extremo a extremo.
La arquitectura de red ilustrada en la FIG. 3B, proporciona la interfaz que puede ser necesaria para permitir interacción entre el CP 328 (o nodos y funciones dentro del CP) y el controlador de AS 332. Esta interfaz se puede usar para permitir gestión de sesión consciente de aplicación de PDU para el tráfico de aplicaciones que requiere rutas eficientes de extremo a extremo.
En términos amplios, realizaciones de la presente invención proporcionan métodos por los que información de gestión de Plano de Usuario (UP) puede intercambiarse entre una Función de Aplicaciones (AF) que soporta una o más aplicaciones y una función de gestión de sesiones (SMF). La AF es típicamente una función exterior una red compatible con 3GPP (en algunos ejemplos esto puede ser un servidor o conjunto de servidores que proporcionan un servicio a UE conectados a la red conforme con 3GPP, mientras que en otros ejemplos la AF puede ser una función ejemplificada dentro de un entorno de computación en el borde Móvil fuera de la Red Central conforme con 3GPP o exterior un RAN conforme con 3GPP). En algunas realizaciones, la AF se denomina controlador de AS. Una AF puede ser una función fuera del alcance de un estándar 3GPP. Una AF puede ejemplificarse en un Servidor de Aplicaciones fuera de la red central 3GPP, y puede funcionar como controlador responsable de funciones tales como (re)ubicación de AS (o, (re)selección de AS) dentro de la DN local.
La SMF es una función de red conforme con 3GPP, típicamente dentro de un plano de control (CP), configurado para gestionar flujos de tráfico que típicamente están dentro de un segmento dado de la red. En términos simples, el intercambio de información de gestión de UP asociado con un flujo de tráfico particular puede ser iniciado desde ya sea la AF asociada con el flujo de tráfico o la SMF. En caso de intercambio de información iniciado por AF, la información de gestión de UP proporcionada por la AF puede comprender requisitos de tráfico de aplicaciones soportadas por la AF. En caso de intercambio de información iniciado por SMF, la información de gestión de UP proporcionada por la SMF puede comprender información de política de operador o acontecimientos, y la AF puede responder con información de requisitos de tráfico de aplicaciones soportadas por la AF. En algunas realizaciones, otras entidades de red pueden desencadenar este proceso al transmitir un mensaje a la SMF, y la SMF puede iniciar el proceso en respuesta a recepción de este tipo de petición.
Una Función de Aplicaciones puede enviar peticiones para influir en decisiones de enrutamiento de SMF para tráfico de sesiones de PDU. Las peticiones de AF pueden influir en (re)selección de UPF y permitir enrutar tráfico de usuario a un acceso local a una red de Datos (identificada por un Identificador de Acceso a Red de Datos (DNAI)).
La Función de Aplicaciones que emite tales peticiones se supone que pertenece a la PLMN que da servicio al UE. La Función de Aplicaciones puede emitir peticiones en nombre de aplicaciones que no pertenece a la PLMN que da servicio al UE.
Si el operador no permite a una Función de Aplicaciones acceder a la red directamente, la Función de Aplicaciones usará la NEF para interactuar con la 5GC. Esta operación puede seguir estipulaciones de estándares técnicos relevantes, tales como, por ejemplo, cláusula 6.2.10 de Estándar Técnico 3GPP TS 23.501 V0.3.1 (marzo de 2017). En realizaciones donde la AF no accede a la red directamente, se puede proporcionar una NEF para proporcionar una interfaz que permita a la AF acceder a las funciones de CP de la red. Si bien se puede proporcionar una AF de confianza la capacidad para interactuar con Funciones de CP de CN, es probable que haya demasiadas funciones en algunas redes para proporcionar acceso a funciones de CP a cada una de ellas. En cambio, la NEF puede servir como proxy para AF fuera de la CN para intercambiar información con funciones de CP. Mediante el uso de una NEF, una A<f>pueden proveerse de una senda para comunicar con una función de CP, pero puede no conocer directamente la dirección o nombre de red de la función con la que se comunica.
La Función de Aplicaciones puede estar a cargo de la (re)selección o reubicación de las aplicaciones dentro de la DN local. Para esta finalidad, la AF puede pedir recibir notificaciones acerca de acontecimientos relacionados con sesiones de PDU.
En algunas realizaciones, para una AF que tiene permitido interactuar directamente con las NF 5GC, peticiones de AF en relación con sesiones de PDU de UE individuales en marcha, pueden enviarse a la PCF por medio de N5. En algunas realizaciones, las peticiones de AF pueden enviarse por medio de la NEF. Peticiones que múltiples UE pretendidos pueden enviarse por medio de la NEF y puede tener por objetivo múltiples PCF. La PCF puede entonces transformar las peticiones de AF en políticas que se aplican a sesiones de PDU. Los expertos en la técnica apreciarán que la transformación de una petición de AF en política puede lograrse de varias maneras diferentes, incluida la generación de una política que puede ser transmitida por la PCF a una UPF o un conjunto de UPF que controla el manejo de tráfico asociado con flujos identificados dentro de una sesión, la generación de la política se realiza según la petición de AF recibida. Cuando la AF se ha suscrito a notificaciones de SMF, tales notificaciones pueden enviarse a la AF directamente o por medio de la NEF.
La PCF también pueden suscribirse a tales notificaciones.
Tales peticiones de AF pueden contener al menos:
Información para identificar el tráfico a enrutar. El tráfico se puede identificar en la petición de AF por:
Ya sea un Número de Red de Datos (DNN) u otra clase de identificador de DN y posiblemente información se segmentación (p. ej. Información de Asistencia de Selección Único Segmento de Red (S-NSSAI) o un Identificador de Servicio de AF.
Cuando la AF proporciona un Identificador de Servicio de AF es decir, un identificador del servicio en nombre del que la AF está emitiendo la petición, una Función de Red Central 5G (p. ej. la NEF o PCF) puede correlacionar este identificador en un DNN pretendida e información de segmentación (S-NSSAI)
Cuando la NEF procesa la petición de AF el Identificador de Servicio de AF se puede usar para autorizar la petición de AF.
un identificador de aplicación o información de filtrado de tráfico (p. ej. una dirección IP 5-tuplas). El identificador de aplicación se refiere a una aplicación que maneja tráfico de UP y puede ser usada por la UPF para detectar el tráfico de la aplicación. La AF también pueden asociar Descripciones de Filtro de Paquetes (PFD) con el identificador de aplicación, pero esta asociación puede hacerse por medio de una petición separada.
Información acerca de los requisitos de enrutamiento de tráfico N6 para tráfico identificado por la información anterior. Debe entenderse que N6 se refiere a la interfaz entre una UPF y una DN externa a la CN. Esta información acerca del enrutamiento de requisitos de tráfico se puede proporcionar en forma de una lista de ID de perfil de enrutamiento que cada una corresponde a una única ubicación de hospedaje de la aplicación en la DN local, cuando aplicaciones se ejemplifican estáticamente (es decir, los ID de perfil de enrutamiento corresponden cada uno a un DNAI). Cuando los DNAI donde aplicaciones se ejemplifican pueden variar dinámicamente entonces, esto se puede proporcionar en forma de una lista de DNAI e información de enrutamiento N6 asociada. En función de la información acerca de los requisitos de enrutamiento de tráfico N6, que en algunas realizaciones puede comprender los ID de perfil de enrutamiento, la PCF determina una lista de ID de perfiles de direccionamiento de tráfico que corresponde cada uno a un comportamiento de direccionamiento que se preconfigura en la SMF o UPF. La PCF transmite los ID de política de direccionamiento de tráfico a la SMF. Los ID de políticas de direccionamiento de tráfico se relacionan con el mecanismo que habilita direccionamiento de tráfico a la DN. Si la AF interactúa con la PCF por medio de la NEF, puede indicar al menos una del DNN y la (las) ubicación(es) de hospedaje, en forma de dirección(es) o nombre(s), de la aplicación, y la NEF puede correlacionar la información a los ID de perfil de enrutamiento. En una realización, la SMF puede funcionar para recibir los ID de política de direccionamiento de tráfico y determinar cuál de los ID de política de direccionamiento de tráfico y los correspondientes comportamientos de direccionamiento de tráfico debe aplicarse. La SMF pasa los ID seleccionados de política de direccionamiento de tráfico a la UPF. En una realización, la UPF puede funcionar para identificar correspondientes parámetros de direccionamiento de tráfico que se preconfiguran y se asocian con los ID de política de direccionamiento de tráfico seleccionados. La UPF puede funcionar además para aplicar los correspondientes parámetros de direccionamiento de tráfico cuando se maneja tráfico de datos.
Los requisitos de enrutamiento de tráfico N6 se relacionan con el mecanismo que permite el direccionamiento de tráfico en el acceso local a la DN. Se espera que correspondan a reglas locales configuradas en las UPF a fin de soportar direccionamiento de tráfico. Los ID de perfil de enrutamiento pueden referirse a una política preacordada entre la AF y la 5GC, o en una realización alternativa simplemente pueden referirse a un requisito de enrutamiento predefinido. Esta política puede referirse a diferentes ID de políticas de direccionamiento enviados a la SMF. En algunas implementaciones, las políticas pueden basarse en otras condiciones, tales como condiciones temporales (p. ej. en función del momento del día, etc.)
Ubicaciones potenciales de las aplicaciones hacia las que se debe aplicar el enrutamiento de tráfico. La ubicación potencial de una aplicación se expresa o puede expresarse como lista de DNAI. En algunas realizaciones, cuando la AF interactúa con la PCF por medio de la NEF, la AF puede proporcionar a la PCF o NEF una lista de dirección(es) de hospedaje o nombre(s) de hospedaje de las aplicaciones, que se traslada a una lista de DNAI por la NEF. En algunas realizaciones, cuando la<a>F interactúa con la PCF por medio de la NEF, la NEF puede correlacionar la información de Identificador de Servicio de AF proporcionada por la AF a una lista de DNAI. En cualquier caso, los DNAI pueden, por ejemplo, usarse para (re)selección de UPF.
Las peticiones de AF también pueden contener:
Información sobre los UE para los que se va a enrutar tráfico. Esto puede corresponder a UE individuales identificados usando ya sea un Identificador Externo tal como los definidos en TS23.682, o un MSISDN como se describe en TS23.003, o una dirección IP/Prefijo, o puede corresponder a un grupo de UE identificado por un Identificador de Grupo, p. ej. un Identificador de Grupo Externo tal como los definidos en TS23.682, o cualquier UE al que se aplica la petición que está accediendo a una combinación de DNN, S-NSSAI y DNAi, como puede ser identificado por un indicador. En un caso o una realización en la que el tipo de PDU es IP, cuando la AF proporciona una dirección IP/Prefijo de un UE que permite a la PCF identificar la sesión PDU-CAN para la que se aplica esta petición, y la petición de AF aplica se únicamente a la sesión PDU-CAN actual de ese UE. En este caso, información adicional tal como la identidad de UE también puede proporcionarse para ayudar a la PCF a identificar la sesión PDU-CAN correcta.
De otro modo la petición se puede aplicar a cualquier sesión de PDU futura que coincide con los parámetros en la petición de AF.
Cuando la petición de AF tiene como objetivo cualquier UE o un grupo de UE, la petición de AF es probable que influya en múltiples sesiones de PDU posiblemente reciben servicio de múltiples SMF y PCF.
Cuando la petición de AF tiene por objetivo un grupo de UE proporciona uno o varios Identificadores de Grupo en su petición. En algunas realizaciones miembros del grupo tienen la información de grupo en su suscripción (es decir, un Identificador de Grupo) almacenado en la UDM. En una implementación, la información de grupo puede ser recuperada por la SMF, por ejemplo sobre interfaz N10, y pasarse a la PCF, por ejemplo sobre interfaz N7, en la preparación de sesión PDU-CAN. Esta implementación permite que el Identificador de Grupo también sea proporcionado a la AMF, por ejemplo sobre interfaz N8. En algunas realizaciones, el identificador de Grupo puede almacenarse en el UDR (que actúa como Repositorio de Perfiles de Suscripción "SPR") como datos no estándar de PCF. En algunas realizaciones un UE puede pertenecer a múltiples grupos.
La información sobre cuándo se va a aplicar el enrutamiento de tráfico (p. ej. una condición de validez temporal). El uso de una condición de validez temporal permite asociar un tiempo de caducidad con la petición de AF, o permite a la condición aplicarse durante ventanas de tiempo definidas. Estas ventanas de tiempo definidas se pueden repetir o ser únicas.
Información sobre dónde van a estar (condición de validez espacial) los UE cuando se aplica el enrutamiento de tráfico. En una realización, esto se proporciona en forma de identificadores geográficos o topológicos tales como identificadores de nodo de RAN, que indica los posibles nodos de RAN de servicio de los UE cuando se aplica el enrutamiento de tráfico. Si la AF interactúa con la PCF por medio de la NEF, proporciona, o en algunas realizaciones puede proporcionar, una lista de identificador(es) de zona geográfica, y la NEF correlaciona la información a identificadores de nodo de RAN. En una realización, condiciones de validez espacial se pueden proporcionar en forma de área(s) de interés. Las área(s) de interés puede(n) incluir, por ejemplo, un área geográfica o como área topológica que define el área de interés con respecto a una topología de red. Un área de interés puede especificarse usando un identificador espacial tal como un ID de área de rastreo, ID de nodo de (R)AN, ID de celda, etc. Si la AF interactúa con la PCF por medio de la NEF, puede proporcionar una lista de identificador(es) de zona geográfica y la NEF puede correlacionar la información a áreas de interés en función de información preconfigurada. La preconfiguración puede ser hecha por una función de plano de gestión. La preconfiguración puede incluir la correlación de ID de zona ^ información/configuración de zona ^ área de interés (o ID(s) de nodo de RAN o ID(s) de celda).
Como alternativa, en un procedimiento separado que ha sucedido previamente, la AF puede proporcionar la información de correlación de ID de zona ^ info/configuración de zona a la NEF, y la función de plano de gestión configura la NEF con información de nodo de RAN o información de ubicación de celda o información áreas de interés predefinidas. La NEF puede usar la información proporcionada por la AF y la información proporcionada por el plano de gestión (ambas son información preconfigurada) para hacer la correlación.
Suscripción de AF a los siguientes acontecimientos.
Notificaciones acerca de acontecimientos de gestión de camino de UP: Un cambio de DNAI para la UPF que da servicio al UE en el momento del cambio de la UPF. La correspondiente notificación acerca de un cambio desde el DNAI fuente para tener como DNAI pretendido enviado por la SMF a la AF incluye la Identidad del DNAI pretendido y la dirección de la UPF de anclaje. En algunas realizaciones, la notificación también puede incluir la dirección IP/prefijo del UE, la información de identidad de UE (p. ej. ya sea un Identificador Externo o un MSISDN) y la información de enrutamiento N6 relacionada con la red central.
En algunas realizaciones, al menos una de la información de identificación de UE y la información de enrutamiento N6 relacionada con la red central puede no requerirse si el tipo de sesión de PDU es IP.
La suscripción puede ser para al menos una de notificación temprana y notificación tardía. En caso de una suscripción para notificación temprana, la SMF envía la notificación antes de ejecutar la (re)selección de UPF. En caso de una suscripción para notificación tardía, la SMF envía la notificación cuando se ha completado la (re)selección de UPF.
Una función de Aplicaciones puede enviar peticiones para influir en decisiones de enrutamiento de SMF, para suscripción a acontecimiento o para ambos.
La PCF, en función de información recibida de la AF, política del operador, etc. autoriza la petición recibida de la función de aplicación y determina la política de direccionamiento de tráfico. La política de direccionamiento de tráfico puede indicar una lista de perfiles de direccionamiento de tráfico adecuados configurados en SMF, y en algunas realizaciones la política de direccionamiento de tráfico puede incluir la información de enrutamiento N6, por ejemplo, en casos donde la información de enrutamiento N6 asociada con la aplicación es proporcionada explícitamente por la AF. Un perfil de direccionamiento de tráfico puede incluir al menos uno del ID de perfil de enrutamiento que soporta y el correspondiente Identificador de Acceso a Red de Datos (DNAI). Los DNAI se relacionan con la información considerada por SMF para selección de UPF, p. ej. para desviar (localmente) algunos filtros de tráfico de coincidencia de tráfico proporcionados por la PCF.
La PCF acusa recibo de la petición a la AF o a la NEF.
En el procedimiento de establecimiento de sesión, el UE puede proporcionar identificadores de aplicación en la petición de sesión, que indican que la sesión de p Du está pretendida o dedicada para la aplicación identificada por el (los) identificador(es) de aplicación. Cuando el DNN en la petición de sesión apunta a una DN local y cuando un identificador de aplicación se incluye en la petición de sesión, la SMF puede iniciar autenticación/autorización de terceros, como se describe en la cláusula 5.6.6, TS23.501, para validar el acceso de aplicación.
Durante el procedimiento de establecimiento de sesión de PDU (una realización del cual se muestra en la FIG.
28A), la SMF puede obtener información de grupo de suscripción (p. ej. Identificador de Grupo de IMSI) del UDR por medio de la UDM (p. ej. etapas 2806 y 2808). La SMF proporciona el identificador de aplicación (si disponible) y el grupo de suscripción la información a la PCF (p. ej. etapa 2814 o 2818) para aplicar política de operador.
Para sesiones PDU-CAN que corresponden a la petición de AF, la PCF proporciona a la SMF reglas de PCC que pueden contener al menos uno de: al menos una de una información de aplicación (es decir, identificador de aplicación), e información acerca de los DNAI hacia los que se debe aplicar el enrutamiento de tráfico; y al menos una de una lista de ID de perfil de direccionamiento de tráfico, condiciones de validez espacial, e información sobre suscripción de AF a acontecimientos de SMF. En realizaciones donde la información de enrutamiento N6 asociada a la aplicación se proporciona explícitamente en la petición de AF, la PCF también puede proporcionar la información de enrutamiento N6 a la SMF como parte de reglas de PCC. Esto se hace al proporcionar políticas en preparación de sesión PDU-CAN o al iniciar un procedimiento de modificación de sesión PDU-CAN. En algunas realizaciones, la PCF evalúa periódicamente la condición de validez temporal de la petición de AF e informa a la SMF para activar o desactivar la correspondientes reglas de PCC según el resultado de evaluación.
Si las reglas de PCC activadas contienen condiciones de validez espacial, la SMF se suscribe para recibir información de movilidad de UE de la AMF, asociada con el UE que o deja la áreas de interés especificadas en las condiciones de validez espacial. La SMF usa la información de movilidad de UE y las condiciones de validez espacial para determinar si las reglas de PCC son válidas para la aplicación.
Cuando las reglas de PCC son válidas, la SMF puede, en función de políticas locales, tener en cuenta la información en las reglas de PCC para:
(re)seleccionar UPF(s) para sesiones de PDU. La SMF es responsable de manejar la correlación entre la ubicación UE (TAI / Cell-Id) y DNAI(s) asociados con UPF y aplicaciones. La SMF es responsable de la selección de las UPF que dan servicio a una sesión de PDU. Esta operación puede seguir estipulaciones de estándares técnicos relevantes, tales como, por ejemplo, cláusula 6.3.3 de Estándar Técnico 3GPP TS 23.501 V0.3.1 (marzo de 2017).
activar mecanismos para multihoming de tráfico o refuerzo de un Clasificador de UL (UL CL). Tales mecanismos pueden seguir estipulaciones de estándares técnicos relevantes, tales como, por ejemplo, cláusula 5.3.5 de Estándar Técnico 3GPP TS 23.501 V0.3.1 (marzo de 2017). Esto puede incluir proporcionar a la UPF reglas de reenvío de tráfico (p. ej. escape) y la información de enrutamiento N6 asociada si la información de enrutamiento N6 es parte de las reglas de PCC. Una regla de reenvío de tráfico puede incluir un identificador de aplicación y un ID de política de direccionamiento de tráfico. El identificador de aplicación se refiere a reglas de detección de tráfico de aplicaciones configuradas en la UPF. En una realización, un encabezado de aplicación se puede usar para asociar el identificador de aplicación con las reglas de detección de tráfico de aplicaciones.
informar a la Función de Aplicaciones de la (re)selección del camino de UP (p. ej. cambiar de DNAI y ubicación de sesión de PDU).
La SMF puede configurar la UPF para informar detección de tráfico de aplicaciones. Según la configuración, con la detección de tráfico de aplicaciones la UPF notifica a la SMF acerca del respectivo identificador de aplicación. La SMF puede usar el identificador de aplicación informado y otra información para obtener reglas de PCC de la PCF para aplicar influencia de AF en enrutamiento de tráfico a la sesión de PDU. Por consiguiente, la SMF puede aplicar una configuración a la UPF para configurar políticas de manejo de tráfico en función de reglas y configuraciones asociadas con la AF como se identifica por el identificador de aplicación informado. En algunas realizaciones, la SMF puede reseleccionar una UPF nueva y configurar la UPF nueva para manejar el tráfico de aplicaciones.
En algunas realizaciones, cuando el UE proporciona un identificador de aplicación durante el establecimiento de una sesión de PDU, la SMF puede funcionar para transmitir el identificador de aplicación a la DN. En algunas implementaciones, la SMF puede funcionar para transmitir el identificador de aplicación a la entidad de autenticación/autorización para la DN. Un nodo de red, entidad o función dentro de la DN puede funcionar para realizar autenticación/autorización específica de aplicación en función del identificador de aplicación recibido. En realizaciones alternativas, el identificador de aplicación no es proporcionado por la SMF al nodo de red, entidad o función dentro de la DN como entrada. En cambio, el nodo de red, entidad o función dentro de la DN devuelve una lista de identificadores de aplicación a la SMF. En este caso la SMF debe verificar el identificador de aplicación proporcionado por el UE contra la aplicación. Estas realizaciones difieren en que el identificador de aplicación se proporciona a la DN como entrada al proceso de autenticación/autorización. Como resultado, la autenticación/autorización puede ser lista de identificadores específica de aplicación devuelta por la DN a fin de proporcionar autorización específica de aplicación.
La FIG. 4 ilustra un escenario de reubicación de aplicación dentro de un entorno virtualizado, donde la aplicación App-1 (p. ej. una aplicación de retransmisión de vídeo) se reubica en tres etapas, por ejemplo, debido a cuestiones de cargas. La primera etapa tiene lugar dentro del DNAI-1 y es invisible para la 5GC. La 5GC reselecciona DNAI-2 (cambiando desde el DNAI-1 inicial) en respuesta a la etapa de reubicación 2, y entonces la 5GC reselecciona UPF-2 (cambiando desde UPF-1) y DNAI-2 (cambiando desde DNAI-2) con respecto a la etapa de reubicación de aplicación 3. La tercera etapa sucede en el Centro de Datos-A y la Centro de Datos-B. El movimiento de la función de aplicación al segundo centro de datos es un acontecimiento que puede desencadenar reselección de UPF.
Dos realizaciones para desencadenar reselección de UPF/DNAI se discuten a continuación.
En una primera realización, un DNAI se usa sin influencia de AF en enrutamiento de tráfico. En este caso, la influencia de AF en enrutamiento de tráfico (es decir, reselección de UPF/reconfiguración de direccionamiento de tráfico) puede realizarse después de la detección de tráfico de aplicaciones en la UPF o en la DN. Esto es, la UPF o la AF puede transmitir una notificación hacia una función de plano de control que indica que una sesión contiene tráfico de datos asociado con la aplicación ("detección de tráfico de aplicación") al transmitir, por ejemplo, una petición de reselección de direccionamiento de tráfico. En algunas realizaciones, esto puede ser realizado por una AF que transmite una petición o notificación hacia la SMF, opcionalmente a través de interacción con la NEF. En otros ejemplos una UPF puede transmitir la petición o notificación en respuesta a detección de tráfico en una sesión con una función de aplicación dentro de una DN accedida a través de la UPF. En respuesta a recepción de la petición de reselección de direccionamiento de tráfico, la entidad de plano de control puede ya sea pedir o invocar un proceso de reselección de direccionamiento de tráfico (a veces denominado "desencadenar" reselección de direccionamiento de tráfico). En algunas realizaciones, la AF puede además transmitir una petición de reselección de UPF a la entidad de plano de control del plano de control para reseleccionar la UPF (a veces denominado "desencadenar" reselección de UPF). La eficiencia de camino de extremo a extremo se aplica así a únicamente parte del tráfico asociado con la sesión de PDU.
En una segunda realización, DNAI se usa con influencia de AF en enrutamiento de tráfico. En esta realización, el UE proporciona un identificador de aplicación a la SMF como parte de la petición de sesión. Este identificador de aplicación puede asociarse con un identificador de sesión de PDU, que indica que la sesión de PDU está pensada o dedicada para tráfico asociado con la aplicación. Este identificador se puede usar para indicar a funciones en el camino de UP que se deben aplicar reglas o políticas particulares de manejo de tráfico, o una política particular de enrutamiento de tráfico. Esto permite configurar una función UPF por una función de plano de control al enviar una política de manejo de tráfico que indica cómo debe manejarse cualquiera o todos los flujos de tráfico con un identificador particular. Por ejemplo, una política de enrutamiento de tráfico se puede definir que asegura ese tráfico de datos asociado con la sesión de PDU se enruta a través de un camino definido a través de la CN acercándose o alejándose de la DN asociada con la aplicación.
La eficiencia de camino de extremo a extremo puede por lo tanto ofrecerse al tráfico de aplicaciones desde el mismo principio del proceso de reubicación. En algunas realizaciones, si el UE usa la misma sesión de PDU para ambas de la aplicación identificada y otra aplicación, el camino de UP puede no ser óptimamente eficiente para la otra aplicación. En estos casos se puede lograr eficiencia de camino mejorada después de la detección del tráfico de aplicaciones asociadas con la otra aplicación. En algunas de tales realizaciones, la UPF o la AF, puede determinar que la sesión contiene tráfico asociado con otra aplicación (o función de aplicación) y una función de plano de control (tal como la SMF) puede notificarse del tráfico de aplicaciones detectado para desencadenar la función de plano de control para que reseleccione direccionamiento de tráfico, como se describe en la primera realización.
Como ejemplo, la segunda realización puede aplicarse cuando el UE desea acceder a una aplicación en una DN local que tiene un requisito estricto en eficiencia de ruta de extremo a extremo. La primera realización, por ejemplo, puede aplicarse en otros escenarios (es decir, donde los requisitos de eficiencia de camino de extremo a extremo de la aplicación caen por debajo de un umbral predeterminado).
Cuando un identificador de aplicación es proporcionado por el UE, la SMF puede iniciar autenticación/autorización de terceros para el uso de la sesión de PDU para la aplicación. La autenticación/autorización de terceros puede ser útil como gestión de UP específica de aplicación se puede aplicar a la sesión de PDU según el identificador de aplicación. La autenticación/autorización de terceros puede evitar situaciones en las que no se puede confiar en la información recibida del UE (p. ej. el identificador de aplicación). Por ejemplo, un mecanismo de autenticación/autorización de terceros descrito en 5.6.6, TS23.501 usa el plano de usuario para intercambio de información o comunicación entre la SMF y la función de autenticación/autorización de terceros. En una realización, la presente solicitud propone extender el mecanismo para permitir llevar a cabo autenticación/autorización de terceros por medio de la NEF (que puede permitir llevar al cabo la autenticación/autorización de terceros, en un plano de control extendido). Al permitir acceso a través de la NEF, dependiendo del nivel de acceso proporcionado, la función de autenticación/autorización de terceros puede ser capaz de realizar funciones equivalentes a una AF. Esta realización proporciona funcionalidad adicional para soportar casos en los que la función de autenticación/autorización de terceros no<se encuentra en la DN. En una implementación, la n>E<f proporciona la interfaz y funcionalidad para proporcionar>la función de autenticación/autorización de terceros con la capacidad para actuar como AF.
En el establecimiento de una sesión de PDU para un DN:
- En algunas realizaciones, el UE puede ser autenticado/autorizado por un tercero, que se puede ubicar en la DN, p. ej. un servidor DN-AAA.
Si el UE proporciona información de autenticación/autorización durante el establecimiento de la sesión de PDU, y la SMF determina que se requiere autenticación/autorización de terceros del establecimiento de sesión de PDU en función de la política de DN o configuración local, la SMF pasa la información de autenticación/autorización del UE al tercero. En una realización, si el tercero se encuentra en la DN, la información se puede pasar al tercero en la DN a través de la UPF. En una<realización, si el tercero no está en la>D<n>,<la información se puede pasar al tercero por medio de la NEF. Cuando se usa la NEF, el tercero puede comportarse como>A<f>.<Si la SMF determina que se>requiere autenticación/autorización de terceros del establecimiento de sesión de PDU pero el UE no ha proporcionado información de autenticación/autorización, entonces la SMF puede rechazar el establecimiento de sesión de PDU.
En una implementación, el tercero puede autenticar/autorizar el establecimiento de sesión de PDU y devolver el resultado de autenticación/autorización a la SMF por medio de la UPF. En una implementación, el tercero puede autenticar/autorizar el establecimiento de sesión de PDU y devolver el resultado de autenticación/autorización a la SMF por medio de la NEF.
Si el UE proporciona a la SMF un identificador de aplicación durante el establecimiento de la sesión de PDU, la SMF puede pasar el identificador de aplicación al tercero. El tercero puede realizar autenticación/autorización específica de aplicación según el identificador de aplicación.
La SMF puede determinar si usar la UPF o la NEF para al menos una autenticación de tercero según política de DN, autorización según política de DN, configuración local y el identificador de aplicación proporcionado por el UE.
La al menos una de la autenticación y autorización de DN tiene lugar con el propósito de autorización de sesión de PDU además de:
La autenticación de acceso a 5GC manejada por AMF (En una realización la autenticación puede realizarse según el método descrito en la cláusula 5.2 de TS 23.501).
La autorización de sesión de PDU con relación a datos de suscripción recuperados de UDM impuesto por SMF.
En función de políticas locales la SMF puede iniciar al menos una de autenticación y autorización de DN como parte del establecimiento de sesión de PDU.
Si el UE proporciona un identificador de aplicación durante el establecimiento de la sesión de PDU y si la UPF se usa para autenticación/autorización de terceros, el direccionamiento de tráfico en la UPF se puede configurar según el identificador de aplicación. Si el UE proporciona un identificador de aplicación durante el establecimiento de la sesión de PDU y si la NEF se usa para autenticación/autorización de terceros, la SMF transmite el DNN, la S-NSSAI y el identificador de aplicación a la NEF, punto en el que la NEF puede seleccionar la AF (p. ej. la función de autenticación/autorización de terceros) según la información transmitida por la SMF (p. ej. el DNN recibida, S-NSSAI, y el identificador de aplicación).
El UE puede proporcionar, sobre NAS, información de SM requerida para soportar autenticación de usuario por el tercero.
En algunas realizaciones, cuando SMF añade un anclaje de sesión de PDU (tal como el anclaje de sesión de PDU definido en la cláusula 5.6.4 de TS 23.501) a una autenticación y/o autorización de terceros de sesión de PDU puede no llevarse a cabo. En algunas realizaciones, políticas de SMF pueden requerir a la SMF que notifique al tercero cuando una nueva dirección IP se ha añadido o retirado de una sesión de PDU, o cuando una dirección IP existente asociada con una sesión se ha cambiado a través de la modificación o sustitución de un prefijo.
Una indicación de rechazo de establecimiento de sesión de PDU puede ser transmitida por SMF al UE por medio de NAS SM.
En algunas realizaciones, un tercero puede revocar la autorización para una sesión de PDU. En algunas realizaciones, el tercero puede revocar la autorización para una sesión de PDU en cualquier instante.
Haciendo referencia a la FIG. 5, se presenta un diagrama de señalización que ilustra una realización de notificación de ubicación o reubicación de AS.
En la etapa 500 la NEF 314 recibe una notificación de ubicación, o reubicación, de AS basada en interfaz de programa de aplicación (API) del controlador de AS 332. En las figuras el término (re)ubicación se refiere a ya sea una notificación de ubicación o una notificación de reubicación. El término (re)selección de manera similar se refiere a ya sea selección o reselección, según sea la situación.
La notificación puede incluir la (las) ubicación(es) de AS adecuada para usar, y que puede tenerse en cuenta durante selección o reselección de UP según sea la situación. En caso de una reubicación AS para una sesión existente, la notificación puede indicar la nueva ubicación(es) de AS para usarse desde este punto en adelante. La notificación puede incluir algunos o todos de los siguientes rasgos:
La (las) ubicación(es) de AS, que pueden especificarse usando dirección de red tal como dirección IP, Dirección MAC, o algún otro tipo de información conocida que identifique dirección.
Un indicador de direccionamiento de tráfico, que indica si el direccionamiento de tráfico desde UP 326 al AS debe configurarse por el CP o ser manejado por la red de AS 334.
Información de tiempo que indica cuándo se aplica la (re)ubicación de AS. En una realización no limitativa, la información de tiempo está vacía, que implica que la (re)ubicación de AS procede inmediatamente.
información de ubicación de UE que indica que la (re)ubicación de AS se aplica cuando el UE 102 está presente dentro de la ubicación especificada (p. ej., ubicación geográfica). En una realización no limitativa, la información de ubicación está vacía, lo que implica que la (re)ubicación de AS procede sin considerar la ubicación de UE.
Un filtro de tráfico que indica el tráfico al que se puede aplicar la (re)ubicación de AS. El tráfico puede pertenecer a sesiones de PDU en marcha (tráfico en marcha) o sesiones de PDU futuras (tráfico futuro). El filtro de tráfico incluye un indicador de aplicación, que indica la aplicación a la que se asocia el tráfico, y un indicador de UE, que identifica el UE 5 al que se asocia el tráfico.
El indicador de UE puede ser la dirección IP asociada con el tráfico. En este caso, el tráfico es tráfico en marcha, y el controlador de AS 332 aprende la dirección IP de la AS. El indicador de UE también puede ser un ID de UE esto es adjudicado por el CP 328 y expuesto al controlador de AS 332 a través de la NEF 314. En este caso, el tráfico puede incluir ambos tráfico en marcha y tráfico futuro.
Opcionalmente, el indicador de UE indica más de un UE 102. Es más, el filtro de tráfico puede no incluir indicador de UE, lo que implica que la (re)ubicación de AS se aplica a tráfico de cualquier (es decir, todos) UE 102 que cumple los criterios definidos por el filtro de tráfico.
En una implementación, la información de ubicación recibida puede comprender una ubicación geográfica. La NEF 314 puede funcionar para convertir la ubicación geográfica recibida en una ubicación asociada con la topología de red, tal como un correspondiente ID de celda, y reenviar a la SMF 310 o la PCF 314 el ID de celda como la ubicación UE a través de la notificación de (re)ubicación de AS. En una implementación, la NEF 314 puede funcionar para reenviar la ubicación geográfica a la SMF 310 o la PCF 314 como la ubicación de UE.
A continuación, en la etapa 502 la NEF 314 envía una petición de autenticación a la Función de Servicio de Autenticación (AUSF) 312 si el controlador de AS 332 no se ubica en el dominio de confianza. La petición de autenticación puede incluir la información de identidad del controlador de AS 332 si la información de identidad de controlador de AS es proporcionada por el controlador de AS 332 en la notificación de (re)ubicación de AS basada en API etapa 500.
En la etapa opcional 504 (mostrada con una línea discontinua), la AUSF 312 obtiene la identidad del controlador de AS 332. La etapa 504 se realiza si la petición de autenticación en la etapa 502 no incluye la identidad de controlador de AS.
En la etapa 506 la AUSF 314 autentica el controlador de AS 332 y envía una respuesta de autenticación a la NEF 314. La respuesta de autenticación indica el resultado de autenticación.
Si la autenticación tiene éxito, la NEF 314 valida la notificación y realiza las siguientes etapas, que se determinan en función de si el reubicación AS se aplica a tráfico en marcha o a sesiones de PDU futuras.
En una implementación, el procedimiento incluye únicamente uno de procedimiento 508 (reubicación AS para sesiones de PDU en marcha) y procedimiento 510 ((re)ubicación de AS para sesiones de PDU futuras). En una implementación, el procedimiento 508 no se utiliza, y el procedimiento 510 se implementa para reubicación AS hecho para sesiones de PDU en marcha, sesión de PDU futura, o una combinación de ambos sesiones de PDU en marcha y futuras. En el caso de que el procedimiento 510 se implemente para sesiones de PDU en marcha, la PCF 314 desencadena que la SMF 310 realice reselección de UP al transmitir un desencadenante de reselección de UP a la SMF 310 con el fin de reseleccionar el correspondiente UP para las sesiones de PDU en marcha. En una implementación alternativa, el procedimiento 510 no se emplea, y únicamente se usa el procedimiento 508. En la implementación alternativa, la SMF 310 puede funcionar para realizar reubicación AS para sesiones de PDU futuras en función de recepción de una notificación de reubicación de AS enviada, por ejemplo, por la NEF 314.
En general, el procedimiento 508 puede realizarse en caso de reubicación AS para sesiones de PDU en marcha (es decir, tráfico en marcha de datos). Primero, la NEF 314 identifica las sesiones de PDU asociadas con el tráfico y la SMF 310 que gestiona las sesiones de PDU identificadas, genera una notificación de reubicación de AS en función de la notificación de reubicación de AS basada en API, y en la etapa 512 envía la notificación de reubicación de AS a la SMF 310 identificada. En una implementación, la NEF 314 puede identificar la SMF 310 al interactuar con la Función de Red de Función de Repositorio (NRF) 318.
Después de recibir la notificación de reubicación de AS, la SMF 310 puede determinar si realizar reselección de UP para el tráfico impactado, según la nueva ubicación(es) de AS, política de operador y modo de Continuidad de Sesión y Servicio (SSC) de las sesiones de PDU.
En la etapa 514A, si la SMF 10 determina que no se requiere reselección de UP, y si la notificación de reubicación de AS indica la necesidad de configuración de direccionamiento de tráfico, la SMF 310 configura direccionamiento de tráfico al actualizar direccionamiento de tráfico en el UP GW 336. Como alternativa, en la etapa 514B, si la SMF 310 determina que se requiere reselección de UP, la SMF 310 inicia el procedimiento de reselección de UP. La SMF 310 puede además configurar direccionamiento de tráfico en el UP GW 336 reseleccionada si es necesario.
En general, el procedimiento 510 se realiza en caso de (re)ubicación de AS aplicando a tráfico futuro. En la etapa 516 la NEF 314 identifica la Función de Control de Políticas (PCF) 314 que es responsable de política de operador para el tráfico futuro, genera una notificación de (re)ubicación de AS en función de la petición de (re)ubicación de AS basada en API, y envía la notificación de (re)ubicación de AS a la PCF 314. La NEF 314 puede identificar la PCF 314 al interactuar con la NRF 318. En la etapa opcional 518 la PCF 314 configura direccionamiento de tráfico con el UP GW 336. En una implementación, la configuración puede aplicarse a todas UP GW 336 que potencialmente pueden usarse para soportar la sesión de PDU pedida (actualmente, o en el futuro). En particular, en función de la notificación de (re)ubicación de AS, datos de suscripción y políticas de operador actuales, la PCF 314 puede generar política de selección de UP y política de direccionamiento de tráfico para el tráfico. En una implementación no se realiza la etapa opcional 518, ya que el direccionamiento de tráfico puede configurarse por separado durante (re)selección de UP (es decir, las etapas 514 o 516).
En una realización, en la que la notificación de (re)ubicación de AS indica la posibilidad de reubicación AS en el futuro, la PCF 314 puede generar una política de selección de modo de continuidad de sesión y servicio (SSC), tal como, por ejemplo, cualquier sesión de PDU asociada con la aplicación debe tener un modo de SSC no igual 1.
Como apreciará fácilmente un trabajador cualificado en la técnica, hay casos en los que la (re)ubicación de AS puede impactar en ambos flujos de tráfico en marcha y flujos de tráfico futuro. En tal caso, pueden tener lugar ambos del procedimiento 508 y el procedimiento 510.
En la etapa 520, NEF 314 envía un acuse de recibo de notificación de (re)ubicación de AS basada en API de regreso al controlador de AS 332, ya sea acusando de recibo de la aceptación de la notificación de (re)ubicación de AS, o rechazando la notificación de (re)ubicación de AS. En caso de un rechazo, el mensaje incluye un código de error que indica la razón del rechazo. En una implementación, la respuesta incluye una ficha de<transacción que identifica la notificación de (re)ubicación de>A<s>.<La ficha de transacción puede ser usada por>el controlador de AS 332 para actualizar más tarde la notificación de (re)ubicación de AS sin al menos uno de proporcionar pleno detalle y para pedir notificación de (re)selección de UP impactado por la notificación de (re)ubicación de AS.
La FIG. 6 ilustra un procedimiento de petición de notificación de (re)selección de UP. En la etapa 600 la NEF 314 recibe una petición de notificación de (re)selección de UP basada en API del Controlador de AS 332. La petición de notificación de (re)selección de UP basada en API puede incluir una ficha de transacción de un procedimiento de notificación de (re)ubicación de AS anterior. La ficha puede indicar que la petición actual corresponde a cualquier procedimiento de (re)selección de UP impactado por esa notificación de (re)ubicación de AS. Como alternativa, la petición puede incluir alguna o toda de la siguiente información:
Información de tiempo, que indica cuándo se aplica la petición de notificación. La información de tiempo puede estar vacía, que indica que la petición de notificación procede inmediatamente.
Información de ubicación de UE, que indica que la petición de notificación se aplica cuando el UE 5 está presente dentro de la ubicación especificada (p. ej., ubicación geográfica). La información de ubicación de UE puede estar vacía, que implica que la petición de notificación procede sin preocuparse de la ubicación de UE.
Filtro de tráfico, que indica el tráfico de datos al que se puede aplicar la petición de notificación. El tráfico puede pertenecer a sesiones de PDU en marcha (tráfico en marcha) o sesiones de PDU futuras (tráfico futuro). El filtro de tráfico también puede incluir un indicador de aplicación que indica una aplicación específica asociada con el tráfico de datos.
El filtro de tráfico opcionalmente incluye un indicador de UE que indica el UE 102 asociado con el tráfico de datos. El indicador de UE puede ser una dirección IP asociada con el tráfico de datos. En este caso, el tráfico de datos es tráfico en marcha, y el controlador de AS 332 aprende la dirección IP de la AS. El indicador de UE también puede ser un ID de UE esto es adjudicado por el CP de CN 328 y expuesto al controlador de AS 332. En este caso, el tráfico de datos puede incluir ambos tráfico en marcha y tráfico futuro. El indicador de UE puede indicar más de un UE 102. Cuando el filtro de tráfico no incluye un indicador de UE, indica que la petición de notificación se aplica a tráfico de datos de cualquier UE 102 que cumple los criterios definidos por el filtro de tráfico.
Tras la recepción de la petición de notificación de (re)selección de UP basada en API, en la etapa 602 la NEF 314 envía una petición de autenticación a la AUSF 312 si el controlador de AS 332 no se encuentra en el dominio de confianza. La petición de autenticación puede incluir información de identificación del controlador de AS 332 si la información es proporcionada por el controlador de AS 332 en la petición de notificación de (re)selección de UP basada en API.
En la etapa opcional 604, la AUSF 312 obtiene la identidad del controlador de AS 332. Esta etapa se realiza si la petición de autenticación 602 no incluye la información de identificación del controlador de AS 332.
En la etapa 30406, la AUSF 312 autentica el controlador de AS 332 y envía una respuesta de autenticación a la NEF 314 que indica el resultado de autenticación.
Cabe señalar que cada una de la petición de autenticación, obtener identificación y las etapas de respuesta de autenticación son opcionales si la petición de notificación de (re)selección de UP basada en API incluye una ficha de transacción.
En la etapa 608 la NEF 314 genera una petición de notificación de (re)selección de UP en función de la petición de notificación de (re)selección de UP basada en API y la envía a la PCF 314. La PCF 314 puede validar la petición y, si la petición es válida, la PCF 314 puede generar una política de notificación de (re)selección de UP en función de la petición de notificación de (re)selección de UP recibida. En la etapa opcional 610 la PCF 314 puede transmitir una respuesta de autenticación de (re)selección de UP a la NEF 314 que indica el resultado de validación.
En la etapa 612, la NEF 314 envía una respuesta de notificación de (re)ubicación UP basada en API de regreso al controlador de AS 332, ya sea acusando recibo de aceptación de la notificación de (re)ubicación de AS, o rechazando la notificación de (re)ubicación de AS. En caso de un rechazo, el mensaje incluye un código de error que indica la razón del rechazo. En una implementación, la respuesta incluye una ficha de transacción que identifica la notificación de (re)ubicación de AS. La ficha de transacción puede ser usada por el controlador de AS 332 para actualizar más tarde la notificación de (re)ubicación de AS sin al menos uno de proporcionar pleno detalle y para pedir notificación de (re)selección de UP impactado por la notificación de (re)ubicación de AS.
La FIG. 7 ilustra un procedimiento de notificación de (re)selección de UP. La SMF 310 inicia un procedimiento de notificación de (re)selección de UP si la notificación de (re)selección de UP se necesita como resultado de un procedimiento de petición de notificación de (re)selección de UP (por ejemplo, como se ha descrito anteriormente), tras realizar (re)selección de UP.
En la etapa 700 la SMF 310 envía una notificación de (re)selección de UP a la NEF 314. La notificación de (re)selección de UP puede incluir al menos una de una ficha de transacción de la correspondiente petición de notificación de (re)selección de UP, una indicación de la ubicación de AS y una indicación de la ubicación de UP GW 336. La información de ubicación puede, por ejemplo, ser en forma de dirección de red.
En la etapa 702 la NEF 314 genera una notificación de (re)selección de UP basada en API en función de la notificación de (re)selección de UP y la transmite al controlador de AS 332. El controlador de AS 332 comunica a la NEF 314 un acuse de recibo de recepción de la notificación de (re)selección de UP basada en API. Antes de enviar el acuse de recibo, el controlador de AS 332 puede realizar las etapas necesarias para el procedimiento de (re)ubicación de AS o (re)ubicación estado de AS, que puede incluir liberar recursos y estructuras de datos, configurar direccionamiento de tráfico, etc.
En la etapa 704, la NEF 314 transmite un acuse de recibo de notificación de (re)selección de UP a la SMF 310 confirmando la recepción del acuse de recibo de notificación de (re)selección de UP basada en API recibido del controlador de AS 332.
La FIG. 8 ilustra un procedimiento para un establecimiento de sesión de PDU amigable con aplicación. En la etapa 800 el controlador de AS 332 inicia un procedimiento de notificación de (re)ubicación de AS con el CP 328 para tráfico futuro asociado con el UE 102 y a una aplicación especificada que genera una política de selección de UP conocedora de aplicación y política de direccionamiento de tráfico.
En la etapa 802 el controlador de AS 332 también inicia un procedimiento de petición de notificación de (re)ubicación de UP con el CP 328 para el tráfico futuro asociado con el UE 102 y a la aplicación especificada que genera la política de selección de UP conocedora de aplicación y política de direccionamiento de tráfico.
En el procedimiento 804, el UE 102 puede iniciar un procedimiento de preparación de sesión cuando tiene tráfico de aplicaciones para transmitir o recibir de la aplicación. En la etapa 806 el UE 102 envía una petición de sesión a la SMF 310 por medio de la Función de Gestión de Acceso y Movilidad (AMF) 308. La petición de sesión puede incluir el ID de sesión y el modo de SSC preferido (opcional). La petición de sesión también puede incluir un identificador de aplicación que indica que es una petición de sesión dedicada para la aplicación. En<la etapa 808 la SMF 310 verifica el contexto de>U<e con la UDM 320 y autoriza la petición de sesión según los>datos de suscripción de usuario.
Si la petición de sesión se autoriza, la SMF 310 inicia un procedimiento de selección de UP 810. En la primera etapa 812, SMF 310 obtiene políticas de operador de la PCF 314, que incluye las políticas amigables con aplicación resultantes del procedimiento de notificación de (re)ubicación de AS 800. En la etapa opcional 814, la SMF 310 selecciona un modo de SSC para la sesión de PDU según la petición de sesión, las políticas de operador, el tipo de UE, y otra información necesaria. Por ejemplo, si la petición incluye el identificador de aplicación pero no modo de SSC preferido y si las políticas de operador indican reubicación AS futura potencial, la SMF 310 puede establecer el modo de SSC de la sesión de PDU a 2 o 3 para permitir reselección de UP para rutas eficientes de extremo a extremo.
En la etapa 816 la SMF 310 interactúa con la UDM 320 para obtener la capacidad de direccionamiento de tráfico entre UP GW candidatas 336 y las ubicaciones de AS y selecciona el camino de UP para la sesión de PDU con respecto a las políticas de operador en función de la información proporcionada por la UDM 320. En la etapa 818 la SMF 310 desencadena la preparación de UP y, si las políticas de operador indican la necesidad de configuración de direccionamiento de tráfico, configura direccionamiento de tráfico en el UP GW 336.
En la etapa 820, SMF 310 transmite una petición de preparación de conexión a la AN 302 para conectar al UP 326. En esta etapa, la AN 302 puede adjudicar recursos de RAN para la sesión de PDU.
Si las políticas de operador indican la necesidad de notificación de (re)selección de UP, en la etapa 822 la SMF 310 notifica al controlador de AS 332 acerca de la selección de UP a través de un procedimiento de notificación de selección de UP.
En la etapa 824 la SMF 310 transmite una respuesta de petición de sesión de PDU al UE 102 por medio de la AMF 308. La respuesta incluye el modo de SSC seleccionado para la sesión de PDU, si el UE 102 no proporcionó modo de SSC preferido en la petición de sesión. En la etapa 826 ocurre transferencia de tráfico desde el UE 102 por medio del UP GW 336.
La FIG. 9 ilustra una procedimiento de reselección de UP conocedor de aplicación para modificación de sesión de PDU. En este procedimiento, en la etapa 900 el UE 102 tiene una sesión de PDU establecida que está llevando el tráfico de aplicaciones por medio del UP-A 326A. Como se muestra en la FIG. 9, la transferencia de tráfico de aplicaciones 902 es por medio del UP-A 326A.
La SMF 310 recibe un desencadenante para reselección de UP para el tráfico de aplicaciones llevado por la sesión de PDU. El desencadenante puede ser desde: un procedimiento de notificación de reubicación de AS 904, que indica una nueva ubicación de AS; un procedimiento de traspaso 906, que indica una nueva AN de servicio; o un desencadenante de política 908 desde la PCF 314 que indica un cambio de política que impacta en la selección de UP de la sesión de PDU.
En respuesta a recibir el desencadenante, en la etapa 910 la SMF 310 envía un mensaje de redirección de sesión al UE 102 por medio de la AMF 308. Esta etapa es opcional si la sesión de PDU establecida va a ser servida o usada con anterioridad según la configuración de modo de SSC.
En la etapa 912, el UE 102 transmite una petición de sesión para preparar una nueva sesión en respuesta a recibir la sesión redirección. Obsérvese que esta etapa también es opcional, ya que únicamente ocurre si se recibe un mensaje de redirección de sesión de la SMF 310.
En la etapa 914 la SMF 310 establece el UP-B 326B para el tráfico de aplicaciones usando un procedimiento de (re)selección de UP La etapa 914 es similar al procedimiento de selección de UP mostrado en la FIG. 7 y descrito anteriormente.
En el caso de que la etapa 912 sea opcional, si la sesión de PDU no es una sesión de PDU dedicada para la aplicación y tiene un modo de SSC de 3, la SMF 310 puede insertar un punto de ramificación en el camino de UP de manera que el UP-A 326A y el UP-B 326B son dos ramificaciones del camino de UP La SMF 310 ordena al punto de ramificación dirigir el tráfico asociado con la aplicación al UP-B 326B, por ejemplo, según la dirección de destino o la combinación de dirección de destino y número de puerto.
En la etapa 916 la SMF 310 envía una respuesta de sesión al UE 102 por medio de la AMF 308 para cerrar la petición de sesión enviada en la etapa 912. Si la sesión de PDU en marcha no es una sesión de PDU dedicada para la aplicación y tiene un modo de SSC de 3, la respuesta debe indicar el tráfico de aplicaciones a redirigir a la nueva sesión de PDU, p. ej., a través de la dirección de destino o la combinación de dirección de destino y número de puerto). El UE 102 realizará redirección de tráfico según la indicación redirección en la respuesta de sesión.
En la etapa 918, la SMF 310 prepara redirección de tráfico desde el UP-A 326A al UP-B 326B para traspasar el tráfico. En la etapa 920 tráfico de aplicaciones futuro continúa, ahora por medio del UP-B 326B.
En una realización, se proporciona un sistema y un método para gestión de SSC y UP influenciada por aplicación para computación en el borde. En la realización, se asume que las aplicaciones (es decir, AS) se despliegan en la red local del operador, es decir, DN local.
Haciendo referencia a la FIG. 10, una función de aplicación (AF) 324 (una función no 3GPP) es responsable de (re)ubicación de AS (o, (re)selección de AS) dentro de la DN local. La función de aplicación 324 interactúa con el CP 328 a través de la NEF 314. El comportamiento de la función de aplicación 324 y la reubicación real de la aplicación o contexto de aplicación todavía no se han definido en el estándar actual, y no son relevantes para la presente solicitud.
El CP de CN 328 tiene información acerca de la capacidad de direccionamiento de tráfico entre las UPF 304 y las ubicaciones de AS. La información es proporcionada por un componente de gestión de red, tal como un gestor de redes en el plano de gestión 330 y usado por la NEF 314 para determinar idoneidad o preferencia de las UPF 304 para la aplicación.
La SMF 310 es responsable de configurar direccionamiento de tráfico en las UPF 304 para enrutar tráfico de UL a la ubicación de AS apropiada a pesar de (re)ubicación de AS.
La DN local es responsable de direccionar tráfico de DL a la UPF 304 apropiada en la cara de (re)selección de UP La UPF 304 reconoce la dirección IP de UE asociada al tráfico de DL como dirección IP válida. Para asegurar que la UPF 304 reconoce la dirección IP de UE, en algunas realizaciones, cada una de las UPF 304 puede hacer uso del mismo espacio de direcciones IP privadas.
El direccionamiento de tráfico de DL puede ser configurado por la función de aplicación 324, o realizarse a través de mecanismos de gestión de movilidad de nivel superior dentro de la DN local. La UPF 304 puede reconocer la dirección IP de UE en el tráfico de DL como identificador válido. Esto se puede lograr por ejemplo al aplicar el mismo espacio de direcciones IP privadas en las UPF 304. Como se señala anteriormente, en realizaciones donde no se usa direcciones IP, se pueden emplear otros tipos de dirección o identificadores. El comportamiento de la DN local para direccionar tráfico de DL no es pertinente para la siguiente discusión.
La interfaz marcada por una línea discontinua en la FIG. 10 todavía no se ha definido en el estándar actual y cómo se estructura no es pertinente para la siguiente discusión.
Esta sección describe la interacción necesaria entre el CP 328 y la función de aplicación 324 para permitir gestión de UP amigable con aplicación para la aplicación que requiere camino eficiente de extremo a extremo.
En esta realización de ejemplo, se asume que la NEF 314 autentica y valida la información recibida de la función de aplicación 324. Como entenderán los expertos en la técnica, esta responsabilidad se puede mover a otras funciones, con los cambios proporcionales en la señalización de control.
Haciendo referencia a la FIG. 11A, se presenta un diagrama de señalización que ilustra una realización de selección de UP influenciada por aplicación realizada por la SMF 310 como parte de establecimiento de sesión. En la etapa 1100 la función de aplicación notifica a la red la (las) ubicación(es) de aplicación para el tráfico de aplicaciones futuro asociado con el UE 102 a través del procedimiento de servicio 'Notificación de (re)ubicación de Aplicación' de la NEF 314, donde la política de selección de UP y el direccionamiento de tráfico regla son generados por la PCF 314. En una implementación, el procedimiento de servicio de Notificación de (Re)ubicación de Aplicación' de la NEF 314 puede implementarse usando cualquier número de métodos diferentes que incluye algunos de los descritos en otra parte en esta solicitud.
En la etapa 1102, la función de aplicación 324 puede suscribirse a notificación de (re)selección de UP 326 para el tráfico de aplicaciones futuro asociado con el UE 102 a través del procedimiento (parte 1) del servicio 'Notificación de (re)selección de UP' de la NEF 314, donde la política de notificación de (re)selección de UP es generada por la PCF 314. En una implementación, el procedimiento del servicio 'Notificación de (re)selección de UP' de la NEF 314 puede implementarse. La etapa 1102 es una etapa opcional, que se puede determinar por la función de aplicación 324. En algunas implementaciones, las etapas 1100 y 1102 pueden funcionar independiente entre sí.
En la etapa 1104 el UE 102 envía una petición de sesión a la SMF 310, que incluye el identificador de DN local. La petición puede incluir el identificador de aplicación, que indica que es una sesión de PDU dedicada para la aplicación. El identificador de DN local y el identificador de aplicación pueden ser dos partes de un identificador integrado (como identificador de DN local o identificador de aplicación) o ser dos identificadores separados.
En la etapa 1106 la SMF 310 verifica el contexto de UE y autoriza la petición de sesión según los datos de suscripción de usuario. En la etapa 1108 la SMF 310 obtiene políticas de operador de la PCF 314, que incluye la política de gestión de UP influenciada por aplicación resultante de las etapas 1100 y 1102. En la etapa 1110 la SMF 310 selecciona un modo de SSC para la sesión de PDU según la petición de sesión, las políticas de operador, el tipo de UE y otra información necesaria. Si la petición de sesión incluye el identificador de aplicación y si las políticas de operador indican movilidad de aplicación (es decir, reubicación de aplicación potencial), la SMF 310 puede seleccionar el modo de SSC 2 para la sesión de PDU. Si la petición de sesión no incluye el identificador de aplicación y si las políticas de operador indican que las aplicaciones potencialmente accedidas por el UE tienen movilidad, la SMF 310 puede seleccionar el modo de SSC 3 para la sesión de PDU.
En la etapa 1112 la SMF 310 puede seleccionar un camino de UP de extremo a extremo para la sesión de PDU con respecto a las políticas de operador. Este camino de extremo a extremo en el UP 326 puede incluir la ubicación de aplicación seleccionada para la sesión de PDU.
En la etapa 1114 la SMF 310 pide a la AN 302 que configure conexión N3. En la etapa opcional 1116, la AN 302 puede adjudicar recurso de RAN para la sesión de PDU.
En la etapa 1118 la AN 302 responde a la SMF 310, que indica la finalización de la preparación de conexión N3.
En la etapa 1120 la SMF 310 prepara el camino de UP En la etapa 1122 la SMF 310 puede configurar el direccionamiento de tráfico sobre la interfaz N6 en la UPF de anclaje 304 del UP 326. En algunas realizaciones, las etapas 1120 y 1122 pueden combinar en una única etapa de preparación integrada en la que la preparación de UP y configuración de direccionamiento de tráfico se realizan juntas.
En la etapa 1124 la SMF 310 puede notificar a la función de aplicación 324 acerca de la selección de camino de UP de extremo a extremo a través del procedimiento (parte 2) de servicio 'Notificación (re)selección de UP' de la NEF 314. La notificación indica la ubicación de sesión de PDU y la ubicación de aplicación. En algunas realizaciones, la ubicación de sesión de PDU se puede usar como la dirección IP de UPF de anclaje. En otras realizaciones, la dirección IP de UE se puede usar para la ubicación de sesión de PDU. La etapa 1124 es opcional, si la etapa 1102 no existe o si la etapa 1102 no indica la necesidad de posnotificación (re)selección de UP
En la etapa 1126 la SMF 310 envía una respuesta de sesión al UE 102 por medio de la AMF 308. La manera en la que se lleva a cabo el establecimiento de Sesión de PDU puede variar en diferentes implementaciones. Los expertos en la técnica apreciarán que este procedimiento puede someterse a estandarización y los detalles de este tipo de procedimiento no son necesariamente pertinentes para la presente solicitud.
La FIG. 11B ilustra una realización alternativa que incluye la etapa opcional adicional 1128. En la etapa 1128 la SMF 310 notifica a la función de aplicación 324 acerca de la selección de camino de UP de extremo a extremo a través del procedimiento (parte 2) de servicio 'Notificación de (re)selección de UP' de la NEF 314. La notificación indica la ubicación de sesión de PDU y la ubicación de aplicación. En algunas realizaciones, la ubicación de sesión de PDU es la dirección IP de UPF de anclaje. En otras realizaciones, la dirección IP del UE se puede usar como la ubicación de sesión de PDU. La etapa 1128 es una etapa de prenotificación que es opcional, por ejemplo si la etapa 1102 no existe o si la etapa 1102 no indica la necesidad de prenotificación de (re)selección de UP
Las FIGs. 12A y 12B son diagramas de señalización que ilustran realizaciones de un procedimiento de reselección de UP influenciado por aplicación. Este procedimiento no cambia la dirección IP de UE y por lo tanto es transparente para el UE 102. La realización de las FIGs. 12A y 12B asume que el UE 102 ya tiene una sesión de PDU establecida por medio del UP-A 326A.
Haciendo referencia a la FIG. 12A, en la etapa 1200 la función de aplicación 324 se suscribe a notificación de (re)selección de UP de la red para el tráfico de aplicaciones asociado a la sesión de PDU a través del procedimiento (parte 1) de servicio "Notificación de (re)selección de UP" de la NEF. La etapa 1200 es opcional, dependiendo de los requisitos de la función de aplicación 324.
En la etapa 1202 la transferencia de tráfico entre el UE 102 y el UP-A 326A puede proceder.
En la etapa 1204 la función de aplicación 324 puede notificar a la red acerca de reubicación de aplicación a través del procedimiento de servicio "Notificación de (re)ubicación de Aplicación" de la NEF 314. Las etapas 1200 y 1204 pueden ser independientes entre sí. La notificación de la red puede incluir la función de aplicación 324 que transmite un mensaje de notificación a uno o más nodos de red que puede, a su vez, proporcionan una notificación a funciones de red central que de otro modo no son alcanzables por la función de aplicación 324.
La SMF 310 puede modificar el camino de UP de extremo a extremo según la reubicación de aplicación y política local cuando es necesario o deseable.
En el procedimiento 1206, la SMF 310 modifica el camino de UP de extremo a extremo donde se requiere reselección de UP En la etapa 128 la SMF 310 reselecciona el UP-B 326B y el direccionamiento de tráfico (sobre la interfaz N6) para la sesión de PDU. Si el modo de SSC de la sesión de PDU es 2, el UP-B 326B se selecciona para sustituir el UP-A 326A. Si el modo de SSC de la sesión de PDU es 3, la SMF 310 inserta una UPF de ramificación o un UL CL UPF en el camino de UP de manera que el UP-A 326A y el UP-B 326B son dos ramificaciones del camino de UP
En la etapa 1210 la SMF 310 notifica a la función de aplicación 324 acerca de la reselección de UP a través del procedimiento (parte 2) de servicio 'Notificación de (re)selección de UP' de la NEF. La etapa 1210 es opcional, si la etapa 1200 no existe o si la función de aplicación 324 ha sido notificada acerca de una (re)selección de UP con el mismo contenido.
En la etapa 1212 la SMF 310 modifica el camino de UP de extremo a extremo de acordar la decisión de reselección de UP. Esto se puede llevar a cabo usando cualquiera de varios métodos diferentes. Los aspectos particulares de dicho método pueden someterse a estandarización, tal como se describe para las etapas 8 - 11 en la cláusula 4.3.5.X.2 del estándar actual. En la etapa 1212, la conexión N3 se puede modificar, la UPF de ramificación o la UL CL UPF (si la hay) se puede configurar para dirigir el tráfico de aplicaciones a UP-B 326B, y se configura la interfaz N6 (es decir, direccionamiento de tráfico) en la UPF de anclaje de UP-B. El direccionamiento de tráfico en la UPF de ramificación o la UL CL UPF puede basarse en la dirección IP de destino, el número de puerto destino, la dirección IP de origen o una combinación de cualquiera de ellos.
En la etapa 1214 la SMF 310 reconfigura el direccionamiento de tráfico en casos donde no se requiere reselección de UP La SMF 310 reconfigura la interfaz N6 en el UPF de anclaje de UP-A 326A para dirigir el tráfico de aplicaciones a la nueva ubicación de aplicación.
En la etapa 1216 la transferencia de tráfico entre el UE 102 y el UP-B 326B puede proceder.
En la etapa 1218 la SMF 310 libera los recursos de sesión de PDU relacionado con el UP-A 326A, si la etapa 1206 tiene lugar y el modo de SSC de la sesión de PDU es 2.
Haciendo referencia a la FIG. 12B, en una realización alternativa la etapa 1200 de la FIG. 12A puede realizarse después de 1204. En la etapa 1220 la transferencia de tráfico entre el UE 102 y el UP-A 326A puede proceder.
En la etapa 1222 la función de aplicación 324 notifica a la red acerca de reubicación de aplicación a través del procedimiento de servicio "Notificación de (re)ubicación de Aplicación" de la NEF 314. Las etapas 1200 y 1222 pueden ser independientes entre sí.
En la etapa 1224 la función de aplicación 324 se suscribe a una notificación de (re)selección de UP de la red para el tráfico de aplicaciones asociado a la sesión de PDU a través del procedimiento (pieza 1) de servicio "Notificación de (re)selección de UP" de la NEF 314. La etapa 1224 es opcional, dependiendo de los requisitos de la función de aplicación 324.
En la etapa 1226, la SMF 310 realiza reselección de camino de UP de extremo a extremo, que incluye al menos uno de reselección de UP y reselección de ubicación de aplicación, según la reubicación de aplicación y la política local.
En la etapa 1228 la SMF 310 reselecciona el camino de UP de extremo a extremo para la sesión de PDU. Si se necesita reselección de UP, la SMF 310 reselecciona el UP-B 326B para la sesión de PDU. Si el modo de SSC de la sesión de PDU es 2, el UP-B 326B se selecciona para sustituir el UP-A 326A. Si el modo de SSC de la sesión de PDU es 3, la SMF 310 inserta una UPF de ramificación o un UL CL UPF en el camino de UP de manera que el UP-A 326A y el UP-B 326B son dos ramificaciones del camino de UP
En la etapa 1230 la SMF 310 notifica a la función de aplicación 324 acerca de la de extremo a extremo camino reselección de UP a través del procedimiento (pieza 2) de 'Notificación de (re)selección de UP' servicio de la NEF 314. La notificación indica la ubicación de UPF de anclaje y la nueva ubicación de aplicación. Esta etapa es una etapa de prenotificación. Es opcional, si la etapa 1224 no existe o si la etapa 1224 no indica la necesidad de (re)selección de UP prenotificación.
En la etapa 1232 la SMF 310 modifica el camino de UP de extremo a extremo según la decisión de etapa 1228. En el caso de que se seleccione UP-B 326B para la sesión de PDU, la SMF 310 modifica el camino de UP de extremo a extremo, como se describe por las etapas 8 - 11 en la cláusula 4.3.5.X.2 del estándar actual. En la etapa 1232, la conexión N3 se modifica, la UPF de ramificación o la UL CL UPF (si la hay) se configura para dirigir el tráfico de aplicaciones al UP-B, 326B y se configura la interfaz N6 (es decir, direccionamiento de tráfico) en la UPF de anclaje de UP-B 326B. El direccionamiento de tráfico en la UPF de ramificación o la UL CL UPF puede basarse en la dirección IP de destino, el número de puerto destino, la dirección IP de origen o una combinación de cualquiera de ellos.
En el caso de que la reselección de UP no sea necesaria, en la etapa 1234 la SMF 310 reconfigura la interfaz N6 en el UPF de anclaje de UP-A 326A para dirigir el tráfico de aplicaciones a la nueva ubicación de aplicación.
En la etapa 1236 la SMF 310 notifica a la función de aplicación 324 acerca de la reselección de camino de UP de extremo a extremo a través del procedimiento (pieza 2) de 'Notificación de (re)selección de UP' servicio de la NEF 314. La etapa 1236 es una etapa posnotificación. Es opcional, si la etapa 1224 no existe o si la etapa 1224 no indica la necesidad de (re)selección de UP posnotificación.
En la etapa 1216 la transferencia de tráfico entre el UE 102 y el UP-B 326B puede proceder.
En la etapa 1240 la SMF 310 libera los recursos de sesión de PDU relacionados con el UP-A 326A, si el modo de SSC de la sesión de PDU es 2 y el UP-B se selecciona para la sesión de PDU en la etapa 1228.
La FIG. 13 es un diagrama de señalización que ilustra una realización de procedimiento de servicio de notificación de (re)ubicación de aplicación.
En la etapa 1300 la NEF 310 recibe un mensaje de Petición de Notificación de (re)ubicación de Aplicación (identificador de aplicación, información de ubicación de aplicación, condición de validez temporal, condición de validez espacial, filtro de tráfico, información de solicitante) de la función de aplicación 324. La información de ubicación de aplicación indica la (nueva) ubicación(es) de aplicación y la estado de la (nueva) ubicación(es) de aplicación La ubicación(es) de aplicación se especifican usando dirección IP La condición de validez temporal indica cuándo procederá la (re)ubicación de aplicación notificada. La invalidez de la condición de validez temporal implica que la (re)ubicación de aplicación procede inmediatamente. La condición de validez espacial indica que la (re)ubicación de aplicación se aplica únicamente al tráfico asociado a UE ubicados dentro de Ubicación(es) especificada(s). La invalidez de la condición de validez espacial implica que la (re)ubicación de aplicación notificada se aplica sin preocuparse de ubicación de UE.
El filtro de tráfico indica el tráfico al que se aplica la aplicación (re)selección, que puede pertenecer a sesiones de PDU en marcha o sesiones de PDU futuras. La invalidez del filtro de tráfico implica que la aplicación (re)selección se aplica a todo tráfico asociado a la aplicación.
El filtro de tráfico puede indicar explícitamente si el tráfico incluye al menos uno de tráfico en marcha y tráfico futuro. El filtro de tráfico puede describirse usando la dirección IP asociada al tráfico. También puede describirse usando ID de UE que es reconocido tanto por la función de aplicación como por la red. La información de solicitante incluye identificador de solicitante.
La NEF 314 notifica la (re)ubicación de aplicación a la función de CP seleccionada, es decir, SMF 310 o PCF 314. La notificación incluye el identificador de transacción de Servicio de Notificación de (re)ubicación de Aplicación, el identificador de aplicación, la (nueva) ubicación(es) de aplicación, los identificadores de las UPF de anclajes adecuadas para selección para cada uno de la (nueva) ubicación(es) de aplicación, y las condiciones de validez espacial y temporal, el filtro de tráfico. Dependiendo de la naturaleza la Información de ubicación en la condición de validez espacial, la NEF 314 puede necesitar trasladar la Información de ubicación en información que es entendible por las funciones de CP El filtro de tráfico puede ser filtro de tráfico trasladado descrito usando identificadores de sesión de PDU. La NEF 314 determina las UPF de anclajes adecuadas para selección según la capacidades de direccionamiento de tráfico entre las UPF y las ubicaciones de aplicaciones notificadas, que es proporcionada por el plano de gestión.
En el procedimiento 1302, la notificación está relacionada con el caso en el que el tráfico impactado pertenece a sesiones de PDU en marcha únicamente. En la etapa 1304 la NEF 314 identifica las sesiones de PDU asociadas al tráfico impactado y la SMF 310 que gestiona las sesiones de PDU, y envía la notificación a la SMF 310. La NEF 314 identifica la S<m>F 310 al interactuar con la UDM 320. En la etapa 1306 la SMF acusa recibo de la recepción de la notificación a la NEF.
En el procedimiento 1308, la notificación puede indicar que el tráfico impactado pertenece a sesiones de PDU futuras (y también posiblemente a sesiones de PDU en marcha). En la etapa 1310 la NEF 314 identifica la PCF 314 que está a cargo de política de operador para las sesiones de PDU y envía la notificación a la PCF 314. La n Ef 314 identifica la Pc F 314 al interactuar con al menos una de la Nr F 318 y la UDM 320. En la etapa 1312 la PCF 314 acusa recibo de la recepción de la notificación a la NEF 314. En la etapa 1314 la PCF 314 genera o actualiza políticas de gestión de UP según la notificación. Si el tráfico impactado pertenece a sesiones de PDU en marcha, en la etapa 1314 la PCF 314 identifica la SMF de servicio 310 del tráfico y notifica a la SMF 310 acerca del cambio de política. En la etapa 1318 la SMF 310 obtiene la actualización de políticas de la PCF 314.
En la etapa 1320 la NEF 314 envía un mensaje de Respuesta de Notificación de (re)ubicación de Aplicación (código de resultado) a la función de aplicación 324. El código de resultado indica la aceptación de la petición o su rechazo.
La FIG. 14 es un diagrama de señalización que ilustra una realización de un Servicio de Suscripción de Notificación de (Re)selección de UP
En la etapa 1402 la NEF 314 recibe el mensaje de Petición de Suscripción de Notificación de (Re)selección de UP ([identificador de transacción] o [identificador de aplicación, condición de validez temporal, condición de validez espacial, filtro de tráfico], tipo de notificación, información de solicitante]) de la función de aplicación 324.
Alternativa A [identificador de transacción]: la petición de suscripción corresponde a una transacción existente de Servicio de Notificación de (re)ubicación de Aplicación. El identificador de transacción de la transacción existente de Servicio de Notificación de (re)ubicación de Aplicación, implica que la petición de suscripción de aplica a cualquier (re)selección de UP impactada por la transacción existente de Servicio de Notificación de (re)ubicación de Aplicación. La NEF 314 puede realizar autenticación y validación simplificadas al verificar el identificador de transacción.
Alternativa B [identificador de aplicación, condición de validez temporal, condición de validez espacial, filtro de tráfico, información de solicitante]: la petición de suscripción es independiente de transacciones existentes de Servicio de Notificación de (re)ubicación de Aplicación. La condición de validez temporal indica cuando la suscripción puede ser eficaz. La invalidez de la condición de validez temporal implica que la suscripción se vuelve eficaz inmediatamente. La condición de validez espacial indica que la suscripción es eficaz únicamente al tráfico de UE ubicados dentro de Ubicación(es) especificada(s). La invalidez de la condición de validez espacial implica que las suscripciones se vuelven eficaces sin preocuparse de la ubicación de UE. El filtro de tráfico indica el tráfico al que se puede aplicar la suscripción, que puede pertenecer a sesiones de PDU en marcha o sesiones de PDU futuras. La invalidez del filtro de tráfico implica que la suscripción se aplica a todo tráfico asociado a la aplicación. El filtro de tráfico puede indicar explícitamente si el tráfico incluye al menos uno de tráfico en marcha y tráfico futuro. El filtro de tráfico puede describirse usando la dirección IP asociada al tráfico. También puede describirse usando ID de UE que es reconocido tanto por la función de aplicación como por la red. El tipo de notificación indica que se pide ya sea prenotificación, posnotificación o ambas prenotificación y posnotificación. La prenotificación implica que se va a enviar notificación antes de configurarse el camino de UP de extremo a extremo; la posnotificación implica que se va a enviar notificación después de la configuración de camino de extremo a extremo. La información de solicitante puede incluir: identificador de solicitante, dirección IP de solicitante y número de puerto de solicitante.
La NEF 314 solicita a la función de CP seleccionada, es decir, SMF 310 o PCF 314, que configure la notificación de (re)selección de UP. La petición puede incluir el identificador de transacción de Servicio de Suscripción de Notificación de (Re)selección de UP, el identificador de NEF, y la información de suscripción en el mensaje de petición excepto por la información de solicitante. Dependiendo de la naturaleza de la Información de ubicación en la condición de validez espacial, la NEF 314 puede necesitar trasladar la Información de ubicación en información que es entendible por las funciones de CP. El filtro de tráfico puede ser filtro de tráfico trasladado descrito usando identificadores de sesión de PDU.
En el procedimiento 1404 el tráfico impactado pertenece a sesiones de PDU en marcha únicamente. En la etapa 1406 la NEF 314 identifica las sesiones de PDU a las que se asocia el tráfico y la SMF 310 que gestiona las sesiones de PDU, y envía la petición a la SMF 310 identificada. En la etapa 1408, la SMF 310 responde a la NEF 314, que indica la aceptación de la petición. La NEF 314 identifica la SMF 310 al interactuar con la UDM 320.
En el procedimiento 1410 el tráfico impactado pertenece a sesiones de PDU futuras (y también sesiones de PDU en marcha). En la etapa 1412 la NEF 314 identifica la PCF 314 que está a cargo de la política de operador para las sesiones de PDU a las que se asocia el tráfico impactado y envía la petición a la PCF 314 identificada. En la etapa 1414, la PCF 314 responde a la NEF 314, que indica la aceptación de la petición. La NEF 314 identifica la PCF 314 al interactuar con al menos una de la NRF 318 y la Ud M 320. En la etapa 1416 la PCF 314 genera o actualiza políticas de gestión de UP según la petición. Si el tráfico impactado pertenece a sesiones de PDU en marcha, en la etapa 1418 la PCF 314 identifica la SMF de servicio 310 del tráfico y notifica a la SMF 310 acerca de la cambio de política. En la etapa 1420 la SMF 310 obtiene la actualización de políticas de la PCF 314.
En la etapa 1422 la NEF 314 envía un mensaje de Respuesta de (re)selección de UP Suscripción (código de resultado) a la función de aplicación 324. El código de resultado indica la aceptación de la petición o su rechazo.
Tras realizar (re)selección de UP de extremo a extremo para el tráfico impactado, en la etapa 1424 la SMF 310 notifica a la NEF 314 acerca de la (re)selección de UP. La notificación puede incluir información tal como el identificador de transacción de Servicio de Suscripción de Notificación de (Re)selección de UP, el tipo de notificación, la ubicación de sesión de PDU la ubicación de UPF de anclaje y la ubicación de aplicación. La ubicación de sesión de PDU puede, en algunas realizaciones ser una de la dirección de UPF de anclaje o la dirección de UE para la sesión de PDU. En algunas realizaciones, estas direcciones son direcciones IP. La información de aplicación puede ser en forma de dirección IP u otro identificador de este tipo.
En la etapa 1426 la NEF 314 envía la información de (re)selección de UP a la función de aplicación 324 usando la dirección IP de solicitante y el número de puerto de solicitante.
En la etapa 1428 la función de aplicación 324 responde a la NEF 314 para acusar recibo de la entrega de la notificación. La respuesta indica si la red debe continuar la configuración de camino de extremo a extremo, si el tipo de notificación es prenotificación.
Con una prenotificación, la función de aplicación 324 puede realizar las etapas necesarias para la (re)ubicación de aplicación o procedimiento de (re)ubicación de estado de aplicación, que puede incluir liberar recursos y estructuras de datos, etc. Si la función de aplicación 324 quiere cancelar la (re)ubicación de aplicación, la función de aplicación 324 usa el mensaje de respuesta para informar a la red. Si el tipo de notificación es posnotificación, la función de aplicación 324 sabe que el camino de UP de extremo a extremo está preparado para uso, y puede empezar a dirigir tráfico de DL a la ruta.
En la etapa 1430 la NEF 314 responde a la SMF 310 para acusar recibo de la entrega de la notificación. La respuesta incluye la información recibida de la función de aplicación 324 en la etapa 1428.
En algunas realizaciones funciones de aplicación pueden influir en el enrutamiento de tráfico. Información sobre el UE cuyo tráfico se va a enrutar
La información para identificar UE 102 puede ser ya sea identificadores fijos o identificadores dinámicos Identificadores fijos
SUPI, PEI descritos en la cláusula 5.9 de TS 23.501: Puesto que las aplicaciones de computación en el borde se pueden ubicar en dominios no confiables, estos identificadores no deben describirse en aplicaciones de computación en el borde de terceros.
MSISDN: Se puede usar para computación en el borde de terceros
Identificador externo: Se puede asignar ya sea por operadores o por aplicación de computación en el borde
Identificadores dinámicos
Identificador temporal: Asignado durante procedimiento de registro de movilidad de UE
Dirección IP: asignada durante procedimiento de establecimiento de sesión
Los anteriores dos identificadores se pueden usar para identificar el UE 102 que tiene sesiones de PDU activas. Sin embargo, estos identificadores pueden cambiarse debido a movilidad de UE o reselección de UPF. Adicionalmente, si la sesión de PDU es tipo no IP, la dirección IP es inaplicable. Así, estos identificadores dinámicos pueden no ser adecuados para aplicaciones de computación en el borde.
Propuesta 1: Ya sea Identificador Externo o MSISDN se usa para identificar el UE cuyo tráfico se va a enrutar.
2 Identificadores para grupo de UE
En algunos escenarios, las actualizaciones de enrutamiento de tráfico pueden aplicarse a un grupo de UE. Si hay un gran número de UE y los identificadores de UE se incluyen en el mensaje enviado desde la aplicación de computación en el borde a la CN, este mensaje sería grande. Se deben proponer métodos alternativos. A continuación se dan posibles métodos.
Área geográficas: la cobertura de PLMN se puede dividir en zonas, cada zona tiene un identificador de zona (ZID). El operador puede informar a la aplicación de computación en el borde acerca de la correlación entre ubicación geográfica y ZID. No hay necesidad de estandarizar la ZID.
Prefijo de IP: Es posible que el grupo de UE para una aplicación dada pueda asignarse un intervalo de direcciones IP. El intervalo de IP puede reservarse para indicar el grupo de UE. Sin embargo, esta solución no es aplicable a tipo de tráfico no IP
Nombre de Dominio de Red (DNN): Cada aplicación de computación en el borde puede tener un único nombre reconocido por CN. El DNN puede indicar al UE quién puede acceder al DNN.
Identificador de Aplicación (AID): Si una DN proporciona múltiples aplicaciones, cada aplicación puede tener un identificador de aplicación. El identificador de aplicación se puede representar por el puerto de servidor de aplicaciones para tráfico IP.
Combinaciones de cualquiera atributos anteriores se pueden usar para identificar grupo de UE.
Propuesta 2: Una combinación de DNN, AID y ZID se puede usar para identificar un grupo de UE.
3. Información sobre dónde dirigir el tráfico: Esto puede ser uno (o ambos) del DNN de red de datos local y la dirección IP del servidor de aplicaciones.
Propuesta 3: Ya sea DNN de red de datos local o dirección IP del servidor de aplicaciones se puede usar para indicar el destino de enrutamiento.
4. Ubicaciones potenciales de la aplicación a donde se debe aplicar el enrutamiento de tráfico: Las ubicaciones potenciales de la aplicación pueden ser ya sea DNN de redes de datos locales que hospedan el servidor de aplicaciones.
Como alternativa, se pueden usar las direcciones IP de servidor de aplicaciones. La gestión de entidades de red puede configurar el CP acerca de las capacidades de transportación enlace entre las UPF y servidores de aplicaciones. Hay una contribución separada para clarificar esta cuestión.
Propuesta 4: Ya sea las DNN de redes de datos locales o direcciones IP de servidores de aplicaciones se pueden usar para indicar ubicaciones potenciales de aplicación para enrutamiento de tráfico.
5. Información para identificar el tráfico a enrutar
Una vez se ha identificado el UE 102, se puede usar información adicional para identificar el tráfico a enrutar.
DN proporciona 1 aplicación: Si la DN proporciona únicamente una aplicación, el DNN se puede usar para identificar una sesión de PDU.
DN proporciona múltiples aplicaciones: Cada aplicación debe tener un identificador de aplicación (AID). Para tráfico IP, el AID puede ser el número de puerto del servidor de aplicaciones.
Propuesta 5: El DNN se puede usar para identificar sesiones de PDU si la DN proporciona una aplicación de computación en el borde. Si la DN proporciona múltiples aplicaciones, cada DNN y AID se usan para identificar sesiones de PDU.
La petición de función de aplicación puede enrutarse a la SMF por otras funciones de control tales como la NEF o la PCF.
a. En EPC, la Interfaz Rx entre PCRF y Función de Aplicaciones se usa para apoyar a aplicaciones de terceros:
Ejemplos: IMS y Funciones de Aplicación de seguridad pública, SCEF
Seguridad: Esas aplicaciones se consideran ubicadas en dominio de confianza de 3GPP. Hay no problemas importantes con la seguridad.
La información recibida sobre interfaz Rx está pensada para PCRF. Significa que la PCRF procesa la información recibida para tomar decisión de políticas.
b. Aplicaciones de computación en el borde en 5G CN
Seguridad: Las funciones de aplicación de control de computación en el borde se pueden ubicar en dominios no de confianza. Así, la petición de funciones de aplicación de control debe autenticarse y autorizarse. Las funcionalidades acordadas actuales de NEF incluyen funcionalidades de autenticación/autorización, pero no PCF.
Para aplicaciones de computación en el borde, la información desde funciones de aplicación de control puede estar pensada para SMF para posible reselección de UPF; la PCF no procesa esta información. Por tanto las funciones de aplicación de control no deben enviar su petición a PCF. Propuesta 6: La NEF se usa como interfaz entre funciones de aplicación de control y Funciones de CP de CN. Una función de aplicación puede enviar peticiones por medio de NEF para influir en decisiones de enrutamiento de SMF para tráfico de sesión de PDU. Esto puede influenciar a la selección de UPF y permitir enrutar tráfico de usuario a un acceso local a una red de datos
Tales peticiones pueden contener al menos:
En algunas implementaciones, las peticiones pueden incluir información para identificar el tráfico a enrutar. El DNN se puede usar para identificar sesiones de PDU si la DN proporciona una aplicación de computación en el borde. Si la DN proporciona múltiples aplicaciones, DNN y AID (Identificador de Aplicación) se usan para identificar sesiones de PDU.
En algunas implementaciones, el número de puerto del servidor de aplicaciones se puede usar como AID. Información sobre dónde dirigir el tráfico. Ya sea DNN de red de datos local o dirección IP del servidor de aplicaciones se puede usar para indicar el destino de enrutamiento. Ubicaciones potenciales de la aplicación a dónde se debe aplicar el enrutamiento de tráfico. Ya sea las DNN de redes de datos locales o direcciones IP de servidores de aplicaciones se pueden usar para indicar ubicaciones potenciales de aplicación para enrutamiento de tráfico. El tráfico se puede identificar por el DNN cuando la Función de Aplicaciones es la única Función de Aplicaciones hospedada en la DN local, o si de otro modo no hay oportunidad de confusión; de otro modo, una combinación de DNN y un identificador de aplicación o información de filtrado de tráfico se puede usar para identificar el tráfico de aplicaciones.
NOTA 1: Correlación entre identificador de aplicación e información de filtrado de tráfico (tal como dirección IP de la Función de Aplicaciones que recibe el tráfico) se puede configurar en la NEF.
- En algunas implementaciones, las peticiones pueden incluir información sobre dónde dirigir el tráfico, tal como el d Nn (p. ej. si todo tráfico de la sesión de PDU se enruta a la Función de Aplicaciones) o la dirección IP de la Función de Aplicaciones.
- En algunas implementaciones, las peticiones pueden incluir ubicaciones potenciales de la aplicación a donde se debe aplicar el enrutamiento de tráfico. Las ubicaciones potenciales de las AF se pueden indicar usando una dirección IP de la AF que maneja tráfico que la NEF (o la AF si es de confianza para el operador como se describe en la cláusula 6.2.X) correlaciona a anclajes de sesión de PDU específicos a la DN local.
NOTA 2: La dirección IP usada para identificar el caso de la AF que maneja tráfico puede ser diferente de la dirección IP de la misma instancia de AF usada por el UE para interactuar con ella.
En algunas implementaciones, las peticiones pueden incluir información sobre los UE cuyo tráfico se va a enrutar. UE individuales se pueden identificar usando ya sea Identificador Externo o MSISDN. Grupos de UE se pueden identificar por el DNN con el que tienen una sesión de PDU activa, posiblemente junto con un identificador de aplicación o información de filtrado de tráfico. Adicionalmente, para restringir el grupo a UE(s) dentro de cierta área geográfica, también se puede incluir identificadores de zona. NOTA 3: Un identificador de zona se puede correlacionar a un área geográfica. La correlación se configura en ambas NEF y AF. Ya sea Identificador Externo o MSISDN se usa para identificar UE individuales. DNN, AID (Identificador de Aplicación) y ZID (Identificador de Zona) o una combinación de cualquiera de ellos se pueden usar para identificar un grupo de UE
En algunas implementaciones, las peticiones pueden incluir información sobre cuándo (indicación de tiempo) se va a aplicar el enrutamiento de tráfico.
La función de aplicaciones 324 que emite tales peticiones se supone que pertenece a la PLMN que da servicio al UE 102. La función de aplicación 324 puede emitir peticiones en nombre de otras aplicaciones que no pertenecen a la PLMN que da servicio al UE 102.
SMF 310 puede, en función de políticas locales, tener en cuenta esta información para:
(re)seleccionar UPF(s) para sesiones de PDU.
activar mecanismos para multihoming de tráfico o refuerzo de un Clasificador de UL (UL CL). Tales mecanismos se definen en la subcláusula 5.3.5. Esto puede incluir proporcionar a la UPF reglas de reenvío de tráfico (p. ej. ruptura).
informar a la función de aplicación de la (re)selección del camino de UP
Según ciertas implementaciones de la invención, se proporcionan métodos y sistemas para enrutamiento de tráfico en los que una condición de validez espacial se añade como parte de la información proporcionada por la AF.
La AF 324 puede proporcionar información a uno o más nodos o funciones dentro de la CN para influir en decisiones de (re)selección de camino de UP que incluye para escenarios computación en el borde. Sin embargo, típicamente se hace consideración si la información proporcionada por AF es idéntica a la información usada en la CN para (re)selección de camino de UP, en otras palabras, si se necesita correlación de información/procesamiento. La siguiente tabla compara pros y contras cuando correlación/procesamiento es y no necesario.
En función de la información proporcionada en la tabla anterior, algunas realizaciones incluyen un o ambos las siguientes dos alternativas para influencia de AF en enrutamiento de tráfico:
(1) En caso de una AF 324 que interactúa con las funciones de Red Central por medio de una NEF 314, la información proporcionada por la AF 324 y la información usada en la Red Central puede ser diferente. En este tipo de realización, la NEF 314 se puede configurar para realizar el procesamiento/correlación de información.
(2) En caso de una AF 324 que interactúa directamente con las funciones de Red Central, la AF 324 puede implementar la funcionalidad de procesamiento de información de la NEF y proporcionar información a las funciones de CN en un formato que se puede usar en la Red Central.
En algunas aplicaciones, tales como, por ejemplo, una aplicación de MTC que incluye una aplicación de monitorización de acontecimientos o una aplicación sensible a multitud, datos de UL asociados con la aplicación pueden tener que ser enrutados a la misma ubicación de aplicación para recogida, procesamiento y toma de decisiones. Por ejemplo, los datos pueden enrutarse a la misma ubicación de aplicación a fin de procesar la datos, identificar correlaciones de datos, realizar agregación de información, y ya sea tomar una decisión o sacar un resultado para permitir a un operador o un tercero revisar y realizar una acción. En tal caso, la influencia de AF en enrutamiento de tráfico puede someterse a una comprobación de validez espacial, por ejemplo que la ubicación de los UE satisface una restricción espacial cuando se aplica el enrutamiento de tráfico.
Por consiguiente, según algunas realizaciones, una condición de validez espacial se incluye en la información proporcionada por la AF a la CN, que es independiente de las condiciones que influyen en (re)selección de UP
Según algunas realizaciones, la interacción entre el CP y el entorno de aplicación se puede definir o regular como política para beneficiarse de la estructura de política unificada. En algunas realizaciones, el resultado de la interacción entre el CP y el entorno de aplicación es una generación de política o actualización de políticas. Las políticas son políticas de gestión de UP que incluyen políticas de enrutamiento de tráfico. El planteamiento basado en PCF permite a la PCF mantener una visión global de la gestión de UP y, así, abordar consistencia de manera óptima en gestión de UP
Una AF puede enviar peticiones para influir en decisiones de enrutamiento de SMF para tráfico de una o más sesiones de PDU. En algunas implementaciones, la AF envía peticiones a la PCF para influir en estas decisiones de enrutamiento de SMF. Esto puede influir en el proceso de selección de UPF y permitir enrutamiento de tráfico de usuario a un acceso local a una red de Datos (DN). Los expertos en la técnica apreciarán que referencia en este documento a enrutamiento de tráfico un acceso local a una DN se puede entender que incluye transmitir tráfico a un punto de acceso local que puede proporcionar acceso a la DN en cuestión. Este punto de acceso local puede ser local a la CN (o segmento de la CN) o puede ser local a la DN. Topológicamente el acceso local sirve como conexión en la DN.
En algunas implementaciones, una AF puede estar a cargo de decisiones, o una parte de estas, acerca de la (re)selección o reubicación de las aplicaciones dentro de la DN local. En algunas implementaciones, este tipo de AF puede recibir notificaciones acerca de acontecimientos relacionados con sesiones de PDU (y en algunas realizaciones pueden recibir información asociada con aplicaciones que tienen sesiones activas de PDU o que tienen la autorización para iniciar una sesión de PDU a través o con la AF).
En algunas implementaciones, una AF puede enviar las peticiones de (re)selección o reubicación, asociadas con una aplicación hospedad en DN, independientemente entre sí. Se asume que la AF que emite tales peticiones pertenece a la red (p. ej. la PLMN) que da servicio al UE. La AF puede emitir peticiones en nombre de otras aplicaciones que no pertenecen a la red o no son hospedadas por esta (p. ej. PLMN) que da servicio al UE.
Si la AF está dentro del dominio de confianza de la CN, puede interactuar con la PCF directamente. Si la AF está fuera del dominio de confianza, puede interactuar con la PCF por medio de la NEF, y la NEF puede a su vez interactuar con la PCF y comportarse como AF dentro del dominio de confianza en nombre de la AF real fuera del dominio de confianza. En algunas realizaciones, la NEF puede actuar como AF en nombre de un AF real que es residente dentro del dominio de confianza.
En escenarios en los que la AF interactúa con la PCF por medio de la NEF, la información proporcionada por la AF y la información usada en la Red Central 5G (5GC) puede ser de un formato diferente o diferente por naturaleza (p. ej. contener diferentes elementos de información). En algunas implementaciones, la NEF se puede configurar para realizar conversión/correlación de información. En el caso en el que la AF interactúe directamente con la PCF, la AF puede proporcionar información utilizable por la 5GC sin la necesidad de conversión de información.
Las peticiones para influir en decisiones de enrutamiento de SMF para tráfico de sesión de PDU pueden enviarse por una AF. Una Función de Aplicaciones puede enviar un mensaje de Notificación de Ubicación de Aplicación a la PCF. El mensaje puede contener al menos:
Información para identificar el tráfico a enrutar. El tráfico puede ser identificado, por ejemplo, por el DNN y un identificador de aplicación o información de filtrado de tráfico. En algunas implementaciones, el tráfico se puede identificar en la petición AN por el DNN. El DNN se puede usar para identificar el tráfico de una sesión de PDU, y el identificador de aplicación, para indicar un servicio particular de una sesión de PDU. En caso de tráfico IP, en algunas realizaciones se puede incluir información de filtrado de tráfico (p. ej., IP 5-tuple que puede contener direcciones de origen y destino así como número de puertos en cada uno del origen y destino, así como un protocolo usado). En algunas implementaciones, información de segmentación (p. ej., S-NSSAI) puede ser parte de la información de filtrado de tráfico o ser un separado elemento en la petición AN.
Información sobre dónde dirigir el tráfico. Si la AF interactúa con la PCF directamente, puede indicar un perfil de enrutamiento que incluye una lista de Identificadores de Acceso de Red Dinámica (DNAI), cada uno de los cuales puede comprender un acceso local a la DN, y parámetros de enrutamiento de tráfico relacionada con N6s con cada DNAI. Si la AF interactúa con la<p>C<f>por medio de la NEF, puede indicar al menos uno del DNN y la dirección de la aplicación en su comunicaciones. En una realización, los parámetros de enrutamiento de tráfico N6 se pueden configurar en UPF para soportar el mecanismo o implementación de direccionamiento de tráfico en la DN local.
Ubicaciones potenciales de las AF que se pueden usar para determinar dónde debe aplicarse el enrutamiento de tráfico. Las ubicaciones potenciales de las AF pueden, por ejemplo, usarse para selección de UPF. Si la AF interactúa directamente con la PCF, la información asociada con ubicaciones potenciales de las AF (ya sea en términos absolutos o en términos topológicos) se puede proporcionar por los DNAI en el perfil de enrutamiento descrito anteriormente. Si la AF interactúa con la PCF por medio de la NEF, la información en relación con ubicaciones potenciales de las AF se puede proporcionar por la (las) dirección(es)de hospedaje de la aplicación.
Información acerca de los UE cuyo tráfico se va a enrutar. Esto puede corresponder a UE individuales, todos UE, grupos de UE un subconjunto del UE conectados, u otro agrupamiento este tipo. El UE o ago lpamiento de UE puede ser identificado usando cualquiera o una combinación de cualquier de un Identificador Externo, Identificador de Grupo Externo, MSISDN, una dirección IP o prefijo de dirección IP
Información de validez temporal para indicar cuándo se va a aplicar el enrutamiento de tráfico. En algunas implementaciones, la ausencia de la información de validez temporal puede implicar que el enrutamiento de tráfico se aplicará inmediatamente. Debe entenderse que otras condiciones predeterminadas pueden aplicarse si la información de validez temporal se omite.
Información de validez espacial que indica criterios basados en ubicación (p. ej. ubicación(es) geográfica(s) dentro de las que deben ubicarse los UE) que debe usarse para determinar si aplicar el enrutamiento de tráfico. Si está ausente, puede aplicarse una condición predeterminada.
En algunas implementaciones, la AF puede interactuar con la PCF por medio de la NEF. En este caso la NEF se puede configurar para convertir la 'información sobre ubicaciones potenciales de las aplicaciones a donde se debe aplicar el enrutamiento de tráfico' y la 'información donde dirigir el tráfico' en el mensaje en un perfil de enrutamiento y proporciona este perfil de enrutamiento o una indicación del perfil de enrutamiento, a la PCF. Si los perfiles de enrutamiento se pueden pedir y colocar en una lista indexada, únicamente se tiene que proporcionar el índice.
En algunas implementaciones, la PCF, en función de al menos una de información recibida (por ejemplo recibida de la AF o la NEF), una política del operador, posiblemente predefinida, y entradas de otras entidades (p. ej., suscripción usuario, cuota del usuario, RAT actual del usuario, estado de carga red, momento del día, ubicación de UE, APN... que puede ser recibido de otras entidades de red tales como una entidad CSM, un HSS, una función de ingeniería de tráfico o de cualquier número de entidades de plano de control y gestión), puede autorizar una petición recibida de la AF y según la petición determinar una política de direccionamiento de tráfico. La política de direccionamiento de tráfico puede indicar unos perfiles de direccionamiento de tráfico adecuados de un conjunto de perfiles. Cada uno de los perfiles puede especificar la UPF que proporciona el direccionamiento de tráfico y los parámetros de enrutamiento de tráfico N6. Esto puede indicar implícitamente un único DNAI, se configura en la UPF.
En una implementación, la PCF puede proporcionar a la SMF la política de direccionamiento de tráfico. La SMF puede, en función de políticas locales, tener en cuenta esta información para al menos uno de:
(re)seleccionar UPF(s) para sesiones de PDU. La SMF puede realizar selección de perfil de direccionamiento de tráfico en el momento de (re)seleccionar camino de UP. Como un perfil de direccionamiento de tráfico puede implícitamente correlacionarse a un único DNAI (por medio de los parámetros de enrutamiento de tráfico N6 en la perfil), selección de perfil de direccionamiento de tráfico puede implicar correlacionar ubicación UE (TAI/Celda-Id) a DNAI(s) además de selección de UPF; activar mecanismos para multihoming de tráfico o refuerzo de un Clasificador de UL (UL CL). Esto puede incluir proporcionar a la UPF reglas de reenvío de tráfico (p. ej. ruptura); y
configurar enrutamiento de tráfico N6 en la UPF de anclaje según el perfil de direccionamiento de tráfico seleccionado.
Con referencia a la FIG. 15, en una realización de un procedimiento de notificación de (re)ubicación de aplicación, la información de conexión (que incluye calidad de conexión p. ej., número de saltos, prestaciones p. ej., retraso, delay jitter, rendimiento, o atributos p. ej. protocolos soportados y parámetros de protocolo que incluye encabezados de protocolo) entre un DNAI (p. ej., DNAI-1 o DNAI-2) y hospedajes individual de aplicaciones se pueden configurar en la NEF 314 por una entidad de plano de gestión, tal como un gestor de redes, gestor de segmentos o gestor de servicios. Como alternativa, la información de conexión puede ser proporcionada por la AF 324 a la NEF 314. La información de conexión para un DNAI con un hospedaje de aplicaciones, en algunas realizaciones, también se puede denominar requisitos de enrutamiento o perfil de enrutamiento. En otras realizaciones, esta información de conexión puede ser parte del perfil de enrutamiento.
Si la AF 324 no está en el dominio de confianza (p. ej. no dentro de la CN o una red de confianza por la CN), la AF 324 puede interactuar con la PCF 316 por medio de la NEF 314. En este caso, la AF 324 puede proporcionar la ubicación de hospedaje potencial de la aplicación (o un conjunto de ubicaciones asociadas con la aplicación) a la NEF 314 en un mensaje, tal como un mensaje de Notificación de Ubicación de Aplicación. La NEF 314 puede seleccionar DNAI adecuados a asociar con la aplicación según la información y la información de conexión descritas anteriormente. En algunas implementaciones, la NEF 314 también puede realizar la selección según requisitos de QoS asociados con la aplicación hacia la conexión de extremo a extremo (ya sea de manera permanente o en función de una sesión particular). Los requisitos de QoS pueden ser proporcionados por la AF 324 al mismo tiempo que otros datos tales como el mensaje de Notificación de Ubicación de Aplicación, o puede transmitirse por separado. La NEF 314 puede indicar el(los) DNAI seleccionado(s) y la respectiva información de conexión (partes seleccionadas o por completo) a la PCF 316. En algunas implementaciones, la información de conexión (o perfil de enrutamiento, o requisito de enrutamiento) indicada por la NEF 314 se puede configurar en la PCF 316 por una función de plano de gestión tal como gestor de redes, gestor de segmentos o gestor de servicios. En tal caso, puede requerirse a la NEF que indique únicamente un identificador de conexión (o identificador de requisito de enrutamiento o identificador de perfil de enrutamiento) a la PCF. Según el identificador de conexión proporcionado, la PCF 316 puede identificar el detalle de su configuración local. En algunas implementaciones, la PCF 316 puede obtener la información de conexión (o perfil de enrutamiento, o perfil de requisito de enrutamiento) por adelantado de la NEF. En algunas implementaciones, la NEF 314 ha obtenido la información de conexión (o perfil de enrutamiento, o perfil de requisito de enrutamiento) de una AF 324.
Donde una función de plano de gestión actúa para configurar una función de CP, por ejemplo un cambio de configuración a aplicar a una NEF 314, la configuración puede cambiarse después de la recepción de una petición transmitida por una AF 324. En algunas implementaciones, una función de plano de gestión puede utilizar un camino alternativo para configurar una función de CP. Donde convencionalmente una función de plano de gestión configura funciones de CP a través de un sistema de 'Gestión de Elementos' en el plano de gestión, en realizaciones de la presente invención, puede enviarse información de configuración a una función de CP a través de la NEF 314. En este tipo de escenario, la función de plano de gestión se puede considerar que actúa como AF que envía mensajes a la NEF. Esto permite a la NEF 314 reenviar información de configuración o instrucciones sin usar una interfaz de sistema de Gestión de Elementos.
Un DNAI puede asociarse con una o múltiples UPF 304. La asociación puede ser en función del área de servicio de las UPF 304 o el área de servicio del DNAI. Por ejemplo, una UPF 304 puede asociarse con los DNAI que se ubican dentro del área de servicio de la UPF 304. En otros ejemplos, UPF 304 ubicadas dentro del área de servicio de un DNAI se asocian al DNAI. Debe entenderse que el área de servicio se puede definir desde el punto de vista de área geográfica, o puede ser determinada por una función topológica asociada con un área de la red móvil. En algunas realizaciones, la asociación de una UPF 304 y un DNAI puede basarse en virtualización. En este caso, el DNAI puede asociarse con un entorno o plataforma de virtualización (en algunas realizaciones el propio DNAI puede formar el entorno o plataforma). En tales realizaciones, las UPF virtuales ejemplificadas dentro de la realización de virtualización asociada con el DNAI se asocian con el DNAI. Una UPF 304 puede asociarse a uno o múltiples DNAI.
Como la asociación entre UPF 304 y DNAI puede predefinirse, cuando la NEF 314 transmite una indicación de los DNAI adecuados a la PCF 316, implícitamente indica las UPF 304 adecuadas. En algunos escenarios, la selección de un DNAI puede resultar en la selección implícita de un subconjunto de las UPF 304 disponibles.
Un perfil de direccionamiento de tráfico se puede definir entre un DNAI y cada una de las UPF 304 asociadas con él. Este perfil de direccionamiento de tráfico se puede usar para describir el comportamiento de direccionamiento de tráfico (que incluye al menos una de las prestaciones de direccionamiento de tráfico tales como retraso, rendimiento, máximas sesiones de PDU permitidas, etc., y
r parámetros de enrutamiento que incluye encabezados de protocolo) del tráfico de UPF hacia el DNAI. El perfil se puede configurar en PCF 306 por una entidad de plano de gestión tal como gestor de redes, gestor de segmentos, o gestor de servicios. En algunas realizaciones, un perfil de direccionamiento de tráfico se puede configurar en UDM 320 (Gestión Unificada de Datos) o DSF (Función de Almacenamiento de Datos- p. ej. UDR 322) y la PCF 316 necesita obtenerla indicando el DNAI y la UPF 304 a la UDM 320 o DSF (p. ej. UDR 322).
Según los perfiles de enrutamiento, la PCF 316 puede seleccionar perfiles de direccionamiento de tráfico (p. ej., los que proporcionan prestaciones de QoS de coincidencia o soporte de protocolo deseado). Los perfiles seleccionados (a veces denominados los perfiles de direccionamiento de tráfico adecuados, o los perfiles seleccionados de direccionamiento de tráfico adecuados) o una indicación de los perfiles seleccionados pueden ser transmitidos por la PCF a la SMF. La SMF puede imponer, o comenzar a imponer, la política de direccionamiento de tráfico recibida durante establecimiento de sesión o modificación de sesión (o en respuesta a establecimiento de sesión o modificación de sesión). Si los perfiles de direccionamiento de tráfico también se configuran en la SMF, la PCF, en algunas realizaciones, únicamente tendrá que indicar los identificadores de perfil de direccionamiento de tráfico. Si los perfiles de direccionamiento de tráfico no se configuran en la SMF, la PCF 316 puede necesitar proporcionar el contenido de los perfiles de direccionamiento de tráfico a la SMF. En algunas realizaciones, la S<m>F 310 es indicada por los identificadores de perfil de direccionamiento de tráfico transmitidos por la PCF 316 y un indicador SMF 310 puede obtener el contenido de perfil de direccionamiento de tráfico forma una función de CP de terceros, tales como UDM 320 o DSF (p. ej. UDR 322).
Una AF 324 puede enviar peticiones para suscribirse a notificación de (re)selección de camino de UP desde la SMF. La suscripción puede ser para al menos una de notificación temprana y notificación tardía. En caso de una suscripción para notificación temprana, la SMF 310 envía la notificación antes de ejecutar la (re)selección de camino de UP En caso de una suscripción para notificación tardía, la SMF 310 envía la notificación después de haberse completado la (re)selección de camino de UP
Las peticiones de AF 324 suscripción a notificación de (re)selección de camino de UP de la SMF puede contener al menos:
En una implementación, se puede proporcionar información de identificación de tráfico relacionada con la suscripción. En una implementación el tráfico puede ser identificado por el DNN si la AF es la única AF hospeda en la DN local; de otro modo, una combinación de DNN e información de filtrado de tráfico se puede usar para identificar el tráfico de aplicaciones. En una implementación, el DNN puede identificar tráfico en función de al menos uno de: una petición de AF, un identificador de aplicación, e información de filtrado de tráfico. En un ejemplo, el DNN se puede usar para identificar el tráfico de una sesión de PDU, y el identificador de aplicación se puede usar para indicar un servicio particular de una sesión de PDU. En caso de tráfico IP, en algunas realizaciones, se puede incluir información de filtrado de tráfico (p. ej. un IP 5-tuple como se ha discutido anteriormente)
Información sobre los UE cuyo tráfico se relaciona con la suscripción. Esto puede corresponder a UE individuales, todos UE, grupos de UE, identificados usando ya sea un Identificador Externo, Identificador de Grupo Externo, MSISDN, una dirección IP, o un prefijo de dirección IP.
Información sobre cuándo (condición de validez temporal) se va a aplicar la suscripción. La ausencia de esta información puede implicar la suscripción se aplicará inmediatamente.
Información en relación con cualquier condición de validez espacial (la ubicación(es) geográfica(s) dentro de las que debe ubicarse los UE) para determinar si se aplica la suscripción. La ausencia de esta información puede implicar que va a usarse una configuración predeterminada
En algunas realizaciones, la PCF 316, en función de información recibida de la AF (o la NEF), política y entradas del operador desde otras entidades (p. ej., suscripción de usuario, cuota del usuario, RAT actual del usuario, estado de carga de red, momento del día, ubicación de UE, APN...), puede autorizar la petición recibida desde la AF y ya sea proporcionar o seleccionar una política de notificación de acontecimiento de (re)selección de camino de UP
En algunas realizaciones, la PCF 316 puede proporcionar a la SMF 310 la política de notificación de acontecimiento de (re)selección de camino de UP La SMF 310 puede, en función de políticas locales, tener en cuenta esta información para informar a la AF 324 de la (re)selección del camino de UP (cambio de direccionamiento de tráfico).
Suscripción de notificación de (re)selección de UP puede suceder en una cadena, por ejemplo, cuando una AF se suscribe a NEF, que a su vez se suscribe a al menos una de la SMF y PCF. La función de CP en el medio de este tipo de cadena de suscripción (p. ej. en lo ejemplo anterior, la NEF) transmitirá una notificación (en algunos ejemplos esto puede ser reenviando la notificación recibida) a lo largo de la cadena. La función de CP puede mantener su rol en la cadena de suscripción para mantener la correlación entre contexto de suscripción con la función de CP anterior y que de la siguiente función de CP en la cadena. Antes de reenviar una notificación, la función de CP puede procesar la notificación y puede mejorar o enriquecer la información en la notificación, reducir o simplificar la información en la notificación, o trasladar/convertir la información en la notificación.
La SMF 310 puede notificar a la función de red de abonado acerca de la notificación de (re)selección de UP (junto con un identificador de suscripción en la política de notificación de (re)selección de UP proporcionada por la PCF). En otras realizaciones donde este tipo de notificación ya sea no se requiere o en realizaciones, donde la función de red de abonado puede obtener la información a través de otras funciones, la SMF 310 se puede configurar para no transmitir el mensaje de notificación.
En algunas implementaciones, el identificador de función de red de abonado puede indicar una dirección de red asociada con la función de red de abonado. En algunas implementaciones, la SMF interactúa con la función de red de abonado usando directamente el identificador de función de red de abonado (p. ej., a través de IP enrutamiento en el caso el identificador es una dirección IP). En algunas implementaciones, la SMF correlaciona el identificador de función de red abonado a alguna información de enrutamiento (p. ej. información de tunelización) y usa esa información para interactuar con la AF. En algunas implementaciones, la SMF mantiene dicha correlación, p. ej., por una configuración desde las funciones de plano de gestión; en algunas realizaciones, la SMF obtiene la correlación al interactuar con una tercera función de CP, p. ej., la NRF o la UDM, al proporcionar el identificador de función de red de abonado a la tercera función de CP y obtener la correlación en respuesta.
En el caso en el que la AF 324 esté en el dominio de confianza (es decir, cuando la AF interactúa con la PCF directamente):
En algunas realizaciones, la función de red de abonado a la que la SMF 310 envía notificación es la AF 324, y la notificación contiene el identificador de la UPF de anclaje seleccionada de la sesión de PDU. En algunas realizaciones, el identificador UPF indica una dirección de la UPF 304.
En algunas realizaciones, la función de red de abonado a la que la SMF 310 envía notificación es la PCF 316, y la notificación indica el perfil de direccionamiento de tráfico seleccionado (p. ej., por el identificador de perfil de direccionamiento de tráfico). La PCF 316 entonces identifica el correspondiente DNAI e indica el DNAI (junto con un identificador de suscripción en mensaje de petición de notificación de (re)selección de UP) - la PCF 316 realiza traslado de información - a la<a>F de abonado 324. En algunas realizaciones, el DNAI se indica en el formato de dirección de red.
En el caso en el que la AF 324 no está en el dominio de confianza (es decir, cuando la AF interactúa con la PCF por medio de la NEF):
En algunas realizaciones, la función de red de abonado a la que la SMF envía notificación es la NEF, y la notificación indica el identificador de la UPF seleccionada de la sesión de PDU. La NEF puede determinar la dirección de la UPF a exponer y el correspondiente hospedaje de aplicaciones y puede transmitir la información al abonado AF (en algunas realizaciones esto se puede hacer junto con un identificador de suscripción en mensaje de petición de notificación de (re)selección de UP recibida de la AF). En este caso, la NEF se puede considerar que realiza al menos uno de traslado de información y enriquecimiento de información.
En algunas realizaciones, la función de red de abonado a la que la SMF envía notificación es la PCF, y la notificación indica el perfil de direccionamiento de tráfico seleccionado (p. ej., por el identificador de perfil de direccionamiento de tráfico). La PCF puede entonces identificar el correspondiente DNAI y proporcionar una indicación del DNAI (junto con un identificador de suscripción) al abonado NEF, que puede entonces, determinar la dirección del DNAI a exponer y el correspondiente hospedaje de aplicaciones y notifica al abonado AF acerca de la información (junto con un identificador de suscripción en mensaje de petición de notificación de (re)selección de UP recibida de la AF) - la PCF y en algunas realizaciones la NEF, se puede considerar que está realizando al menos uno de traslado de información y enriquecimiento de información.
Una AF puede enviar los anteriores dos tipos de peticiones independientemente. En algunas implementaciones, la AF que emite tales peticiones se asume que pertenece a la PLMN que da servicio al UE. La AF puede emitir peticiones en nombre de otras AF que no pertenecen a la PLMN que dan servicio al UE. La red central de una red 5G puede hacer uso de una función de exposición de red para exponer información de red y capacidades para permitir a la AF interactuar con las CNF con el propósito de influir en gestión de camino de UP y enrutamiento de tráfico, ya sea directamente o por medio de una NEF.
En caso de que la AF interactúe con las CNF por medio de una NEF, la información proporcionada por la AF y la información usada en la CN puede ser formateada u organizada de manera diferente. En tal caso, la NEF se puede configurar para realizar el procesamiento/correlación de información.
En caso de la AF que interactúa directamente con las CNF, la AF puede proporcionar información utilizable por las CNF sin procesamiento/correlación.
La información proporcionada por la AF se convierte a políticas de gestión de UP influenciadas por aplicación que incluye reglas de enrutamiento de tráfico relacionadas con N6 por la PCF y entonces enrutarse a SMF. La SMF puede, en función de políticas locales, tener en cuenta esta información para:
(re)seleccionar UPF(s) para sesiones de PDU.
activar mecanismos para multihoming de tráfico o refuerzo de un Clasificador de UL (UL CL). Esto puede incluir, por ejemplo, proporcionar a la UPF reglas de reenvío de tráfico (p. ej. ruptura).
informar a la Función de Aplicaciones de la (re)selección del camino de UP.
Una AF puede pedir ser notificada acerca de la información de ubicación de UE(s).
En algunas realizaciones, se proporciona un sistema y un método para enrutar tráfico de aplicaciones entre anclajes de sesión de PDU y Af de manejo de tráficos que soportan computación en el borde.
Cuando una aplicación de computación en el borde incluye funcionalidad de movilidad (p. ej. la capacidad de moverse a través de los recursos de computación en el borde, típicamente para rastrear el UE asociada con la aplicación), la dirección de red de la aplicación en el encabezado de PDU puede no ser la misma que la dirección de la ubicación donde se hospeda la aplicación. Esto es porque la reubicación de aplicación es un comportamiento de red no necesariamente conocido por el UE. Como un encabezado de PDU no puede usarse para permitir enrutamiento (sobre la interfaz N6) en este caso, es equivalente a una PDU no estructurada en la UL. Además de esto, el uso de PDU no estructuradas puede ser dependiente de aplicación, y puede suceder a cualquier aplicación de computación en el borde. Por consiguiente, en algunas realizaciones tráfico de aplicaciones de computación en el borde se trata como PDU no estructuradas para tener una estructura de computación en el borde unificada.
En algunas realizaciones, la DN local puede ser responsable de enrutar tráfico de aplicaciones entre anclajes de sesión de PDU y AF que manejan tráfico. En particular, la DN local puede implementar la interfaz N6 para asegurar continuidad de sesión y servicio en presencia de movilidad de UE/aplicación. En algunas realizaciones, la DN local proporciona información de enrutamiento de tráfico relacionada con N6 a la Red Central para configurarse en anclajes de sesión de PDU, es decir, UPF de anclajes de sesiones de PDU asociadas a aplicaciones de computación en el borde.
La computación en el borde permite al operador y servicios de terceros hospedarse en las redes de datos locales, cerrar (al menos una de físicamente y lógicamente (topológicamente)) a la (R)AN de unión del UE. La ubicación cercana de los servicios de computación en el borde permite prestación de servicios eficiente ya que el tráfico de servicios está limitado a los enlaces entre el punto de unión de UE (p. ej. el nodo de Acceso) y los recursos de computación en el borde. Esto lleva a menor latencia de extremo a extremo para tráfico entre la aplicación y el UE. Adicionalmente, la red de transporte global puede experimentar carga reducida ya que se reduce el tráfico de servicio de redes cruzadas.
En algunas realizaciones, se proporciona un método en el que el UE pide sesiones de PDU dedicadas para tráfico asociado con aplicaciones de computación en el borde. En algunas implementaciones, el UE puede transmitir una petición a la SMF para seleccionar si una sesión de PDU dedicada se puede usar para una única aplicación de computación en el borde o compartido por múltiples aplicaciones de computación en el borde. En alguna implementación, el UE puede transmitir la petición a la SMF durante el procedimiento de establecimiento de sesión de PDU.
Una función CN 5G puede seleccionar una UPF cerca del UE y ejecuta el direccionamiento de tráfico desde la UPF a la red de datos local por medio de una interfaz N6. La selección puede basarse en los datos de suscripción, ubicación, política del UE, u otras reglas de tráfico relacionadas.
Debido a la movilidad de usuario o AF, la continuidad de servicio o sesión puede requerirse en función de los requisitos del servicio o la red 5G.
Las redes de datos locales son responsables de implementación apropiada de la interfaz N6 para asegurar continuidad de servicio o sesión en presencia de al menos uno de movilidad de UE y movilidad de AF y proporciona información de enrutamiento de tráfico relacionada con N6 a la red.
La red central 5G puede emplear una función de red que permite exposición de información de red y capacidades a un AF de computación en el borde.
Cabe señalar que, dependiendo del despliegue de operador, ciertas AF pueden tener permitido interactuar directamente con las funciones de plano de control de red con las que necesitan interactuar, mientras que las otras AF necesitan usar la estructura de exposición externa por medio de la NEF.
En algunas realizaciones, la funcionalidad que soporta computación en el borde puede incluir, por ejemplo:
Enrutamiento local: una función de red central puede seleccionar una UPF para dirigir el tráfico de usuario a la red de datos local y configurar la UPF con información de enrutamiento de tráfico relacionada con N6.
Direccionamiento de tráfico: una función de red central puede seleccionar el tráfico a enrutar a las funciones de aplicación en la red de datos local.
Continuidad de sesión y servicio para permitir movilidad de UE y AF.
Selección y reselección de plano de usuario, p. ej., en función de entrada de AF.
Exposición de capacidad de reexposición: muchas funciones de red central pueden intercambiar información con y una AF (p. ej. información acerca de la capacidades de las funciones) por medio de una NEF.
QoS y Cobro: PCF proporciona reglas para Control y Cobro de QoS para el tráfico enrutado a la Red de Datos local.
Una AF puede enviar peticiones para influir en decisiones de enrutamiento de SMF para tráfico de sesión de PDU. Esto puede influir en (re)selección de UPF y permitir enrutar tráfico de usuario a un acceso local a una red de datos
En algunas realizaciones, las peticiones para influir en decisiones de enrutamiento de SMF para tráfico de sesión de PDU pueden contener algo o todo de lo siguiente:
Información para identificar el tráfico a enrutar. El tráfico puede ser identificado por el DNN, y un identificador de aplicación o información de filtrado de tráfico.
Información sobre dónde dirigir el tráfico, tal como al menos una del DNN (p. ej. si todo tráfico de la sesión de PDU se enruta a la aplicación) y la dirección de la aplicación.
Ubicaciones potenciales de la aplicación a dónde se debe aplicar el enrutamiento de tráfico. Las ubicaciones potenciales del tráfico que manejan AF se usan para (re)selección de UPF.
Información de enrutamiento de tráfico relacionada con N6 se configura en UPF. La información puede incluir, por ejemplo, la dirección del extremo de interfaz N6 en la DN local y los parámetros de protocolo usados para la interfaz N6.
Información sobre los UE cuyo tráfico se va a enrutar. UE individuales identificados usando un identificador de UE, tal como un Identificador Externo o MSISDN, todos UE, o grupos de UE seleccionados.
Información sobre cuándo (indicación de tiempo) se va a aplicar el enrutamiento de tráfico.
En la explicación anterior, la AF que emite tales peticiones se asume que pertenece a la PLMN que da servicio al UE. La AF puede emitir peticiones en nombre de otras aplicaciones no residentes dentro de la PLMN que da servicio al UE.
En algunas realizaciones, la SMF puede, en función de políticas locales, tener en cuenta esta información para:
(re)seleccionar UPF(s) para sesiones de PDU.
activar mecanismos para multihoming de tráfico o refuerzo de un Clasificador de UL (UL CL). Esto puede incluir, por ejemplo, proporcionar a la UPF reglas de reenvío de tráfico (p. ej. ruptura).
informar a la AF de la (re)selección del camino de UP
En algunas realizaciones, una AF puede pedir ser notificada acerca de la información de ubicación de UE(s). Las notificaciones pueden ser cualquiera o todas de: una vez, en respuesta a la petición de notificación de AF, periódica, o en respuesta a un cambio en estado. El cambio en estado puede ser, por ejemplo, la llegada o partida de un UE de una ubicación geográfica que ya sea satisface o no cumple una condición de validez espacial.
En una realización, (1) la NEF se configura con la información para permitir correlacionar entre identificador de aplicación y la dirección IP de aplicación. La configuración se puede realizar por un componente de plano de gestión, p. ej. gestor de redes, gestor de segmentos, gestor de servicios.
En una realización, (2) la NEF se configura con la información para permitir correlacionar entre un identificador de zona y un área geográfica. La configuración se puede hacer por un componente de gestión, p. ej. gestor de redes. En algunas realizaciones, se puede hacer por una función de terceros tal como una función de aplicación o un servidor de aplicaciones. Esto puede requerir interacción entre la NEF y el tercero para la configuración. Esto se puede usar para proporcionar zonificación personalizada (a diferencia de zonificación unificada en caso de configuración por el plano de gestión).
En una realización, (3) La NEF traslada información de ubicación de UE (p. ej. identificador de zona, o información de zona sin código) recibida de la aplicación en información (p. ej. IDs) identificar las AN que dan servicio a la zona geográfica.
En una realización, (4) la NEF proporciona información trasladada al CPF seleccionadas tales como SMF o PCF.
En una realización, (5) la AF implementa la funcionalidad de NEF. Esto se puede considerar como NEF embebida dentro de la AF. En tales casos, la interacción entre NEF y CPF tiene lugar entre CPF y la AF, y la interacción entre NEF y AF se convierte en lógica interna de la AF. En figuras ilustradas, esto podría describirse como dibujar una caja alrededor de la NEF y AF.
En una implementación, un método se proporciona para conectar un UE a una red. El método incluye el UE que proporciona un DNN y un identificador de aplicación en una petición de sesión; una SMF que obtiene de una PCF política de operador influenciada por aplicación usando ubicación UE el DNN y el identificador de aplicación. La política de operador puede indexarse en PCF usando, uno de DNN, identificador de aplicación, identificador de UE, ubicación, o una combinación de cualquiera o todas de las opciones. En algunas implementaciones, la política puede asociarse con una condición de validez espacial. En una implementación, según la política la<s>M<f>tiene suficiente información para permitir la selección de un camino de U<p>(p. ej. UPF de anclajes). La SMF puede preparar el camino de Up y configurar direccionamiento de tráfico en la UPF de anclaje (p. ej. tráfico destinado a la dirección IP de la aplicación se enruta a una ubicación particular en la DN local) La<s>M<f>puede configurar el direccionamiento de tráfico porque se configura con la correlación entre identificador de aplicación y la dirección IP de aplicación.
En una implementación, la NEF se configura con información para permitir correlacionar entre identificador de aplicación y una dirección, tal como una dirección IP, asociado con la aplicación. La configuración se puede hacer por un componente de plano de gestión, p. ej. gestor de redes, gestor de segmentos, gestor de servicios.
En una implementación, la NEF se configura con información para permitir correlacionar entre un identificador de zona y un área geográfica. La configuración se puede hacer por un componente de gestión, p. ej. gestor de redes. En algunas realizaciones, se puede hacer por una función de terceros tales como una función de aplicación, un servidor de aplicaciones. Esto puede requerir interacción entre la NEF y el tercero para la configuración. Esto permite zonificación personalizada (a diferencia de zonificación unificada en caso de configuración por el plano de gestión).
En una implementación, la NEF traslada información de ubicación de UE (p. ej. identificador de zona, o información de zona sin código) recibida de la aplicación en información (p. ej. IDs) indicativa de las AN que dan servicio a la zona geográfica. La NEF puede proporcionar la información trasladada al CPF seleccionada tal como SMF o PCF.
En algunas realizaciones, la AF implementa la funcionalidad NEF, y la interacción entre NEF y CPF tiene lugar entre CPF y la AF, y la interacción entre NEF y AF se convierte en lógica interna de la AF.
En una implementación, se proporciona un sistema y un método para mantener un camino de UP eficiente para AF que requieren un camino de UP. En una realización, el sistema y el método permiten gestión de camino de UP y SSC influenciada por AF que se ejecuta entre una AF y el CP de CN para mantener un camino de UP eficiente para AF que requieren el camino de UP Lo siguiente se supone para esta realización:
Las AF que manejan el tráfico desde/hacia el UE se despliegan en una DN local del operador.
Una AF está a cargo de la (re)selección o reubicación de las AF dentro de la DN local. La AF interactúa con las funciones de Plano de Control de red ya sea directamente o por medio de la NEF.
La NEF (o la propia AF cuando la AF interactúa con el CP de CN directamente) determina la lista de UPF adecuadas que proporcionan un camino de UP eficiente hacia ubicaciones de AF potenciales identificadas, y proporciona esta información a la SMF.
También puede suponerse que la NEF puede autenticar y validar la información recibida de la función de aplicación.
La FIG. 16 es un diagrama de señalización que ilustra una realización de una procedimiento de (re)ubicación de notificación de AF. Cabe señalar, sin embargo, que en ciertas realizaciones en las que una AF 324 es de confianza para el operador, la AF 324 puede interactuar directamente con funciones de CN, de manera que la AF 324 también realiza el rol de la Ne F 314 en este método. Se señala en las etapas 1600 - 1608, donde la AF 324 puede participar directamente, en vez de por medio de la NEF 314, en esos casos, donde la AF 324 es de confianza para el operador.
En la etapa 1600 la AF 324 envía una Notificación de (re)ubicación AF (que incluye identificador de aplicación, información de ubicación de AF, condición de validez temporal, condición de validez espacial, filtro de tráfico) a la NEF 314.
En la etapa 1602 la NEF 314 (o la AF 324) selecciona una PCF de servicio 314 usando la NRF 318. En la realización ilustrada en la FIG. 15, la PCF de servicio seleccionada es PCF 318. En algunas realizaciones (no se muestran), la NEF 314 proporciona a la NRF 318 el nombre de DN local, el identificador de aplicación de computación en el borde, una condición de validez espacial (tal como identificadores de nodos de accesos de servicio, ubicación o área geográfica), y la NRF 318 replica a la NEF 314 con la PCF de servicio según todos o cualquier combinación de estos elementos de información. La información puede ser suministrada por la AF 324, o la NEF 314 puede derivar la información en función de entrada proporcionada por la AF 324. Debe entenderse que la información proporcionada por NEF 314 a NRF 318 puede ser proporcionada por la AF 324. La información se puede proporcionar en un mensaje tal como la notificación de A f (re)ubicación, o se puede determinar o derivar por la NEF 314 a través de información proporcionada por la AF 324.
A continuación, en la etapa 1604 la NEF 314 (o la AF 324) procesa la notificación y envía una petición de actualización de políticas de gestión de UP a la PCF 314. En la etapa 1606, la PCF 314 entonces genera o actualiza políticas de gestión de UP según la petición. Si la generación de política/actualización impacta en una sesión de PDU en marcha y la SMF de servicio 310 de la sesión de PDU se ha suscrito a notificación de actualización de políticas, la PCF 314 notifica a la SMF 310 acerca de la actualización de políticas.
En la etapa 1608 la PCF 314 responde a la NEF 314 (o la AF 314) para acusar recibo de recepción de la petición. En el caso de que la PCF 314 responde a la NEF 314 en vez de la AF 324, la NEF 314 acusa recibo, en la etapa 1610, la Notificación de (re)ubicación de AF a la AF 324.
La FIG. 17 es un diagrama de señalización que ilustra una realización de un procedimiento de notificación de (re)selección de UP En algunas realizaciones, la AF 324 es de confianza para el operador, de manera que puede interactuar directamente con la CN. En ese caso, la AF 324 adopta el rol de la NEF 314 en este procedimiento, y se omiten las etapas 1702 y 1712, y las etapas 1704, 1706 y 1708 implican a la AF 324 en vez de la NEF 314.
El método empieza con un procedimiento de notificación de (re)selección de UP 1700. En la etapa 1702 de este procedimiento, la AF 324 envía una petición de Suscripción de Notificación de (Re)selección de UP (que incluye sesión de PDU o identificador de aplicación, condición de validez temporal, condición de validez espacial, filtro de tráfico) a la NEF 314, que indica si se piden al menos uno de notificaciones antes y notificaciones después (re)selección de UP Como se señala anteriormente, esta etapa es opcional y puede no requerirse en realizaciones en las que la AF 324 es de confianza para el operador.
En la etapa 1704 la NEF 314 (o la AF 324, si es de confianza para el operador) interactúa con la NRF 318 para seleccionar una PCF. En la realización ilustrada en la FIG. 16, la PCF seleccionada es PCF 314. En algunas realizaciones, la NEF 314 proporciona a la NRF 318 el nombre de DN local, el identificador de aplicación de computación en el borde, una condición de validez espacial (tal como identificadores de nodo de acceso que dan servicio, ubicación o área geográfica), y la NRF 318 replica a la NEF 314 con la PCF de servicio según todos o cualquier combinación de estos elementos de información. La información puede ser suministrada por la AF 324, o la NEF 314 puede derivar la información en función de entrada proporcionada por la AF 324. Similar a la situación descrita anteriormente, la información proporcionada a la NRF 318 por la NEF 314 puede ser recibida de la 324 en una petición de suscripción de (re)selección notificación. En otras realizaciones, la NRF 318 puede determinar o derivar esta información en función de información recibida de la NEF 314. En la etapa 1706 la NEF 314 (o la AF 324) procesa la petición y envía una petición de actualización de políticas de notificación de (re)selección de UP a la PCF 314.
En la etapa 1708, la PCF 314 genera o actualiza políticas de notificación de (re)selección de UP según la petición recibida. Si la generación de política/actualización impacta en una sesión de PDU en marcha y la SMF de servicio 310 de la sesión de PDU se ha suscrito a notificación de actualización de políticas, la PCF 314 puede enviar un mensaje de notificación a la SMF 310 acerca de la actualización de políticas.
En la etapa 1710, la PCF 314 responde a la NEF 314 (o la AF 324) para acusar recibo de la recepción de la petición. En la realización en la que la AF 324 no interactúa directamente con la CN, la NEF 314 puede enviar un acuse de recibo, en la etapa 1712, de la Suscripción de Notificación de (Re)selección de UP a la AF 324.
Al finalizar el procedimiento de suscripción de Notificación de (Re)selección de UP 1600, se puede realizar el procedimiento de entrega de notificación de (re)selección de UP 1714. Las etapas de procedimiento 1714 se realizan conforme tiene lugar (re)selección de UP o conforme se impone actualización de políticas de notificación de (re)selección de UP
En la etapa 1716 la SMF 310 transmite una notificación de (re)selección de UP a la NEF 314 que sirve como notificación a abonados a la notificación de (re)selección de UP que debe tener lugar (re)selección de UP Esta notificación tiene lugar al menos antes o después de la (re)selección de UP en función del tipo de notificación pedido. Indica la ubicación de sesión de PDU, que puede incluir al menos una de la ubicación del anclaje de sesión de PDU y la dirección IP del UE 102.
Las notificaciones tempranas permiten a la AF 324 preparar las etapas necesarias (p. ej., movilidad de AF 324) relacionadas con (re)selección de UP Las notificaciones tardías permiten a la AF 324 configurar la DN local para enrutar tráfico desde la AF 324.
En la etapa 1718, en respuesta a la recepción de la notificación de (re)selección de UP la NEF 314 procesa la notificación y envía la notificación de (re)selección de UP a la AF 324. La AF 324 puede entonces indicar la ubicación de sesión de PDU y la correspondiente ubicación de aplicación. Esta etapa 1718 es opcional y en algunas realizaciones se realiza únicamente cuando la NEF 314 es usada por la AF 324. En el caso de que no se use la NEF 314, la AF 324 y PCF 316 pueden interactuar directamente entre sí y la AF 324 puede implementar las funciones de otro modo realizadas por la NEF 314 (p. ej., la funcionalidad relacionada con el presente procedimiento). Si se realiza la etapa 1718, en la etapa 1720, la AF 324 acusa recibo de la entrega de la notificación a la NEF 314.
En la etapa 1722, NEF 314 (o la AF 324) acusa recibo de la entrega de la notificación a la SMF 310.
En una implementación, un servicio de "gestión de UP actualización de políticas" es uno en el que la PCF 316 recibe una petición de actualización de políticas de gestión de UP La petición puede incluir identificador(es) de aplicación, los identificadores de las UPF de anclajes adecuadas para selección para cada una de las ubicaciones de aplicación, condición de validez temporal, condición de validez espacial, filtro de tráfico, y enrutamiento N6 de información de tráfico. La salida de este servicio es el resultado de la entrega de la petición.
Durante este servicio, cuando la PCF 316 recibe una petición de actualización de políticas de gestión de UP, la PCF 316 genera o actualiza políticas de gestión de UP por consiguiente, y acusa recibo de la recepción de la petición hacia el solicitante. Si la generación de política/actualización impacta en una sesión de PDU en marcha y la SMF de servicio 310 de la sesión de PDU se ha suscrito a notificación de actualización de políticas, la PCF 316 notifica a la SMF 310 acerca de la actualización de políticas.
En otra implementación, el servicio "Notificación de (re)selección de UP actualización de políticas" es uno en el que la p Cf recibe una petición de actualización de políticas de notificación de (re)selección de UP La petición puede incluir identificador de aplicación, condición de validez temporal, condición de validez espacial, filtro de tráfico, tipo de notificación. La salida del servicio es el resultado de la entrega de la petición.
Durante este servicio, cuando la PCF 316 recibe una petición de actualización de políticas de notificación de (re)selección de UP, puede generar o actualización políticas de notificación de (re)selección de UP por consiguiente, y acusa recibo de la recepción de la petición hacia el solicitante. Si la generación de política/actualización impacta en una sesión de PDU en marcha y la SMF de servicio 310 de la sesión de PDU se ha suscrito a notificación de actualización de políticas, la PCF 316 puede notificar a la SMF 310 acerca de la actualización de políticas.
En una implementación, el servicio "Notificación de (re)ubicación de AF" es uno en el que la NEF 314 recibe una notificación acerca de la (re)ubicación de una AF 324. La notificación de entrada puede incluir un identificador de aplicación, información de ubicación AF, condición de validez temporal, condición de validez espacial, filtro de tráfico, información de enrutamiento de tráfico N6. La salida del servicio es el resultado de la entrega de la Notificación de (re)ubicación de AF.
Durante este servicio, cuando la NEF 314 recibe una Notificación de (re)ubicación de AF, procesa la notificación y pide a la PCF 316 que actualice políticas de gestión de UP, y acusa recibo de la Notificación de (re)ubicación de AF hacia el solicitante.
En una implementación, el servicio "Suscripción de Notificación de (Re)selección de UP" es uno en el que la NEF 314 recibe una suscripción para notificación de (re)selección de UP para notificaciones de (re)selección de UP acontecimientos para tráfico especificado. La suscripción de entrada puede incluir un identificador de aplicación, condición de validez temporal, condición de validez espacial, filtro de tráfico y tipo de notificación. La salida del servicio es el resultado de la Suscripción de Notificación de (Re)selección de UP
Durante este servicio, cuando la NEF 314 recibe una suscripción de Notificación de (Re)selección de UP, puede pedir a la PCF 316 que actualice políticas de notificación de (re)selección de UP, y acuse recibo de la suscripción hacia el solicitante. Cuando la NEF 314 recibe una notificación de (re)selección de UP, identifica la ubicación de la respectiva AF de manejo de tráfico 324 y notifica a los abonados la notificación de (re)selección de UP y la ubicación de AF de manejo de tráfico.
En una implementación, el "servicio Notificación de (re)selección de UP" es uno en el que la SMF 310 tiene una política local que indica una suscripción para notificación de (re)selección de UP para notificaciones de (re)selección de UP acontecimientos para una sesión de PDU en marcha. La entrada para este servicio es la política de notificación de (re)selección de UP, que puede incluir identificador de sesión de PDU, condición de validez temporal, condición de validez espacial, tipo de notificación, e información de suscripción. La información de suscripción indica la NF de abonado. La salida de este servicio es una notificación de (re)selección de UP (que puede incluir información de suscripción, y sesión de PDU información de ubicación). La información de suscripción se usa para identificar la anotación del contexto de suscripción en el NF de abonado.
Durante este procedimiento, cuando la SMF 310 detecta una política local que indica una suscripción para notificación de (re)selección de UP para notificaciones de (re)selección de UP acontecimientos para una sesión de PDU en marcha, registra la suscripción indicada por la política. Cuando la SMF 310 (re)selecciona la UPF para la sesión de PDU, notifica a los abonados la notificación de selección de UP En caso de una suscripción para notificación temprana, la SMF 310 envía la notificación antes de ejecutar la (re)selección de UPF. En este caso, la respuesta a esta notificación puede incluir información de enrutamiento de tráfico relacionada con N6. SMF 310 notifica NEF 314 que notifica AF 324; la AF 324 responde a NEF 314 que entonces responde a SMF 310. La información de enrutamiento de tráfico relacionada con N6 se puede incluir en la respuesta transmitida por la AF 324 a la NEF 314. La NEF 314 puede procesarla antes de enviarla a la SMF 310. El procesamiento puede incluir complementarlo con pedazos de información faltantes, que es específico de protocolo N6, y compilación de encabezado de protocolo. La SMF 310 entonces configura la UPF de anclaje para que soporte o use la interfaz N6 con una AF que maneja tráfico, que puede ser la AF 324 o una AF diferente, según la información de enrutamiento de tráfico relacionada con N6 recibida cuando se ejecuta la (re)selección de UPF.
En caso de una suscripción para notificación tardía, la SMF 310 envía la notificación cuando la (re)selección de UPF se ha completado. En una implementación, se proporciona un método para establecimiento de sesión de PDU pedido por el UE 102. En caso de itinerancia, la AMF 308 puede determinar si una sesión de PDU es a ser establecido en ruptura local (LBO) o Enrutamiento de Inicio. En caso de LBO, el procedimiento es como en el caso de no-itinerancia con la diferencia de que cualquiera o todas de la SMF 310, la UPF 304 y la PCF 316 se pueden ubicar en la red visitada.
Las FIGs. 18A y 18B presentan un diagrama de señalización que ilustra una realización de un procedimiento para Establecimiento de Sesión de PDU pedida por UE para no itinerancia e itinerancia con ruptura local. El procedimiento asume que el UE 102 ya ha se registrado en la AMF 308, así, la AMF 308 ya ha recuperado los datos de suscripción de usuario de la UDM 320.
A fin de establecer una nueva sesión de PDU, el UE 102 genera un nuevo ID de sesión de PDU. El UE 102 inicia el procedimiento de establecimiento de sesión de PDU pedida por, en la etapa 1800 que transmite un mensaje de NAS (S-NSSAI, DNN, identificador de aplicación, ID de sesión de PDU, información de SM N1 (obsérvese que en algunas realizaciones el identificador de aplicación puede ser embebido en la información de SM)) que contiene una petición de Establecimiento de Sesión de PDU dentro de la información de SM N1 a la AMF 308. La Petición de Establecimiento de Sesión de PDU puede incluir un tipo de PDU, modo de SSC, Opciones de Configuración de Protocolo.
Cuando el DNN apunta a una DN local, el mensaje de NAS puede incluir un identificador de aplicación correspondiente a una aplicación de Computación en el Borde hospedados en la DN local. La presencia del identificador de aplicación indica que es una petición para una sesión de PDU dedicada para la aplicación de Computación en el Borde.
El mensaje de NAS enviado por el UE 102 es encapsulado por la AN 308 en un mensaje N2 que debe incluir información de ubicación de Usuario e información de Tipo de Tecnología de Acceso.
La información de SM puede contener Contenedor de Petición SM PDU DN que contiene información para la autorización de sesión de PDU por la DN externa.
En la etapa 1802 la AMF 308 determina que el mensaje corresponde a una petición para una nueva sesión de PDU en función del ID de sesión de PDU que no se usa para cualquier sesión de PDU existente del UE. La AMF 308 selecciona una SMF 310.
En la etapa 1804 la AMF 308 transmite un Petición de SM a SMF 310. La Petición de SM contiene ID Permanente de Abonado, DNN, S-NSSAI, ID de sesión de PDU, ID de AMF, información de SM N1, información de ubicación de Usuario, y Tipo de Tecnología de Acceso. El ID de AMF identifica de manera única la AMF 308 que da servicio al UE 102. La información de SM N1 contiene la Petición de Establecimiento de Sesión de PDU recibida del UE 102.
En la etapa 1806 la SMF 310 transmite los datos de petición de suscripción (ID Permanente de Abonado, DNN) a la UDM 320. Esta etapa es opcional y puede realizarse si la SMF 310 todavía no ha recuperado los datos de suscripción relacionados con SM para el UE relacionado con el DNN, la SMF 310 pide estos datos de suscripción.
Si se realiza la etapa 1806, entonces, en la etapa 1808, la UDM 320 transmite un Respuesta de Datos de Suscripción a la SMF 310. Los datos de suscripción incluyen el tipo(s) de PDU autorizado(s), modo(s) de SSC autorizado(s), perfil de QoS Predeterminado.
La SMF 310 comprueba si la petición de UE es conforme con la suscripción de usuario y con políticas locales. Si no es conforme entonces la SMF 310 rechaza la petición de UE por medio de señalización de NAS SM (que incluye un causa de rechazo de SM relevante) reenviada por la AMF 308, la SMF 310 indica a la AMF 308 que el ID de sesión de PDU a de considerarse como liberado y el resto del procedimiento se omite.
La etapa 1810 es la autenticación/autorización de sesión de PDU, que es desde la SMF 310 a DN 306 por medio de UPF 304. Si la SMF 310 necesita autorizar/autenticar el establecimiento de la sesión de PDU, la SMF 310 selecciona una UPF 304 y desencadena el establecimiento de autenticación/autorización de sesión de PDU. Si el establecimiento de autenticación/autorización de sesión de PDU falla, la SMF 310 termina el procedimiento de establecimiento de sesión de PDU e indica un rechazo al UE 102.
Si se despliega Control de Política y Cobro (PCC) dinámico, entonces, en la etapa 1812, la SMF 310 realiza selección de PCF. En la etapa 1814, la SMF 310 puede iniciar establecimiento de sesión PDU-CAN hacia la PCF 316 para obtener las reglas de PCC predeterminadas para la sesión de PDU. Cabe señalar que, en esta realización particular una finalidad de la etapa 1810 es recibir reglas de PCC antes de seleccionar UPF 304. Si no se necesitan reglas de PCC como entrada para selección de UPF, la etapa 1810 se puede omitir.
En la etapa 1816 la SMF 310 selecciona un modo de SSC para la sesión de PDU. Si no se realiza la etapa 1710, la SMF 310 también puede seleccionar una UPF 304 durante esta etapa. En caso de tipo de PDU IPv4 o IPv6, la SMF 310 puede adjudicar una dirección IP/prefijo para la sesión de PDU.
Si se despliega PCC dinámico y el establecimiento de sesión PDU-CAN no se ha realizado en la etapa 1814, entonces en la etapa 1818 la SMF 310 puede iniciar establecimiento de sesión PDU-CAN hacia la PCF 316 para obtener las reglas de PCC predeterminadas para la sesión de PDU. De otro modo, si se despliega PCC dinámico y el tipo de PDU es IPv4 o IPv6, SMF inicia modificación de sesión PDU-CAN y proporciona la dirección IP de UE/prefijo adjudicado a la PCF 316.
En la etapa 1820 la SMF 310 notifica a la AF 324 acerca de la selección de camino de UP, si la petición de sesión de PDU es para una aplicación de Computación en el Borde y si la AF 324 se ha suscrito a este tipo de notificación temprana relacionado con la sesión de PDU. La notificación indica el anclaje de sesión de PDU.
Si la etapa 1810 no se ha realizado, entonces la SMF inicia un procedimiento de establecimiento de sesión N4 con la UPF 304 seleccionada, de otro modo inicia un procedimiento de modificación de sesión N4 con la UPF 304 seleccionada como se ilustra en la FIG. 17. En particular, en la etapa 1822, la SMF envía un Establecimiento de Sesión N4/Petición de Modificación a la UPF 304 y proporciona reglas de detección de paquete, imposición y creación de informes a instalar en la UPF 304 para esta sesión de PDU. Si Info de Túnel CN es adjudicada por la SMF 310, la Info de Túnel CN se proporciona a UPF 304 en esta etapa. Entonces, en la etapa 1824, la UPF 304 acusa recibo enviando un Establecimiento de Sesión N4/Modificación Respuesta. Si Info de Túnel CN es adjudicado por la UPF 304, la Info de Túnel CN se proporciona a SMF 310 en esta etapa 1824.
En la etapa 1826, la SMF 310 envía un Acuse de recibo de Petición de SM (información de SM N2 (ID de sesión de PDU, Perfil de QoS, Info de Túnel CN), información de SM N1 (Aceptación de Establecimiento de Sesión de PDU (Regla de QoS Autorizada, modo de SSC))) a la AMF 308.
La información SM N2 lleva información que la AMF 308 puede proporcionar a la (R)AN 302. La Info de Túnel CN puede corresponder a la dirección Red Central del túnel N3 correspondiente a la sesión de PDU. El perfil de QoS puede proporcionar a la (R)AN 302 la correlación entre parámetros de QoS e Identificadores de Flujo de QoS. El ID de sesión de PDU puede ser usado por señalización de (R)AN con el UE 102 para indicar al UE 102 la asociación entre recursos de (R)AN y una sesión de PDU para el UE 102. La información de SM N1 puede contener la Aceptación de Establecimiento de Sesión de PDU que la AMF proporciona al UE 102. Múltiples Reglas de QoS Autorizada se pueden incluir en la Aceptación de Establecimiento de Sesión de PDU dentro de la información de SM N1 y en la información de SM N2. El acuse de recibo de Petición de SM puede además contener información que permite a la AMF 308 saber o determinar qué UE 102 es el objetivo de la petición de SMF 310 además de determinar qué acceso hacia el UE 102 usar.
Cabe señalar que la información de acceso se puede proporcionar/usar para permitir el caso en el que un UE es simultáneamente conectado sobre acceso 3GPP y No 3GPP.
En la etapa 1828 AMF 308 envía una petición de sesión de PDU N2 (información de SM N2, Aceptación de Establecimiento de Sesión de PDU) a (R)AN 302. La AMF 308 envía la Aceptación de Establecimiento de Sesión de PDU y la información de SM N2 recibida de la SMF 310 dentro de la petición de sesión de PDU N2 a la (R)AN 302.
En la etapa 1830 la (R)AN 302 puede iniciar un intercambio de señalización específico de AN con el UE 102 que se relaciona con la información recibida de SMF 310. Por ejemplo, en caso de una RAN 3GPP, un Reconfiguración de Conexión de RRC puede tener lugar con el UE 102 estableciendo los Recursos de AN necesarios relacionados con la Reglas de QoS Autorizadas para la petición de sesión de PDU recibida en la etapa 1822.
(R)AN 302 puede también adjudicar información de túnel de (R)AN para la sesión de PDU. (R)AN 302 puede reenviar el mensaje de NAS (Aceptar Establecimiento de Sesión de PDU) proporcionado en la etapa 1824 al UE 102. (R)AN 302 puede proporcionar el mensaje de NAS al UE 102 cuando se establecen los recursos de (R)AN necesarios y la adjudicación de información de túnel de (R)AN son exitosos.
En la etapa 1832 (R)AN 302 envía un Acuse de Recibo de Petición de Sesión de PDU N2 ((R)Info de Túnel AN) a AMF 308. La información de Túnel (R)AN puede corresponder a la Dirección de Red de Acceso del túnel N3 correspondiente a la sesión de PDU.
En la etapa 1834 la AMF 308 puede enviar la Petición de SM (información de SM N2) a SMF 310. Más específicamente, la AMF 308 reenvía la información de SM N2 recibida de (R)AN 302 a la S<m>F 310.
En algunas implementaciones, el UE 102 puede notificar una función CN que ha establecido con éxito la sesión de PDU. En algunas implementaciones, el UE 102 transmite un mensaje de Completo de establecimiento de sesión de PDU NAS para indicar que el UE 102 ha establecido con éxito la sesión de PDU. En algunas implementaciones, el establecimiento exitoso de una sesión en (R)AN 302 indicado en la etapa 1828 sirve como la notificación.
Si la sesión N4 para esta sesión de PDU todavía no se ha establecido, la SMF 310, en la etapa 1836, inicia un procedimiento de Establecimiento de Sesión N4 con la UPF 304. De otro modo, la s Mf 310 inicia un procedimiento de Modificación de Sesión N4 con la UPF 304. La SMF 310 proporciona Info de Túnel AN y Info de Túnel CN. La Info de Túnel CN únicamente necesita proporcionarse si la SMF 310 ha seleccionado Info de Túnel CN en la etapa 1718.
En la etapa 1838 la UPF 304 transmite a la SMF 310 un Establecimiento de Sesión N4/Modificación Respuesta. Después esta etapa, la AMF puede reenviar notificación de acontecimientos relevantes a la SMF 310, por ejemplo en traspaso donde cambia la Información de Túnel de (R)AN o se reubica la AMF 308. En algunas realizaciones, la SMF 310 se suscribe explícitamente a estos acontecimientos. En otras realizaciones, la suscripción es implícita. En la etapa opcional 1842 la SMF 310 reenvía Configuración de dirección IPv6 al UE 102, por medio de UPF 304. En particular, en caso de tipo de PDU IPv6, la SMF 310 genera un Anuncio de Rúter IPv6 y lo envía al UE 102 por medio de N4 y la UPF 304. Debe entenderse que en algunas realizaciones, después de la etapa 1838, la<s>M<f>puede enviar una Petición de SM Acuse de recibo (mostrado como 1840) a la AMF 308. Esto puede ser una respuesta a la Mensaje de petición de SM 1724.
En la etapa 1844 SMF 310 transmite a la AF 324 un mensaje de notificación de selección de UPF (notificación tardía) que informa a la AF 324 acerca de la selección de camino de UP, si la petición de sesión de PDU es para una aplicación de Computación en el Borde y si la AF 324 se ha suscrito a este tipo de notificación tardía relacionado con la sesión de PDU. La notificación indica el anclaje de sesión de PDU. la AMF 308 puede almacenar, para la vida útil de la sesión de PDU, una asociación del ID de sesión de PDU y la SMF ID.
En una realización, se proporciona un procedimiento para gestión de camino de UP SSC influenciada por AF en escenarios de computación en el borde. El procedimiento es entre una AF y el CP de CN para mantener un camino de UP eficiente para AF que lo requieren. Para este procedimiento, se asume que las redes de datos locales que hospedaje aplicaciones de Computación en el Borde son responsables de la implementación de interfaz N6 apropiada para asegurar continuidad de servicio o sesión en presencia de al menos uno de movilidad de UE y movilidad de AF. En este caso, reselección de camino de UP puede ser transparente al UE 5.
En una implementación, la reconfiguración de anclaje de sesión de PDU se debe a reubicación de aplicación. En este caso, la reubicación de aplicación no impacta en la decisión de selección de UPF de la SMF y la SMF 10 únicamente necesita para reconfigurar el enrutamiento de tráfico N6 en el anclaje de sesión de PDU para asegurar entrega de tráfico de UL a la nueva ubicación de AF de manejo de tráfico y reconocimiento de tráfico de DL de la nueva ubicación de AF de manejo de tráfico
La FIG. 19 es un diagrama de señalización que ilustra una realización de un reconfiguración de anclaje de sesión de PDU debido a reubicación de aplicación. Como se muestra en la FIG. 19, en la etapa 1900 el UE 102 tiene una sesión de PDU establecida con la UPF 1304A como el anclaje de sesión de PDU. En la etapa 1902 la SMF 310 recibe un desencadenante para actualizar el configuración de enrutamiento de tráfico N6 en la UPF1 304A. Esto puede ser desencadenado por, por ejemplo, la reubicación de aplicación, cambio de política, etc. En la etapa 1904 la SMF 310 notifica la AF 324 acerca de la reselección de camino de UP, si la AF 324 se ha suscrito a este tipo de notificación temprana. La notificación indica la UPF1 304A como el anclaje de sesión de PDU. A continuación, en la etapa 1906, la SMF 310 reconfigura el enrutamiento de tráfico N6 en la UPF1 304A. En la etapa 1908 la SMF 310 notifica a la AF 324 acerca de la reselección de camino de UP, si la AF 324 se ha suscrito a este tipo de notificación tardía. La notificación indica la UPF1 304A como el nuevo anclaje de sesión de PDU. En algunas realizaciones, AF 324 se suscribe a notificación temprana únicamente, de manera que la etapa 1908 no se realiza. En algunas realizaciones, AF 324 se suscribe a notificación tardía únicamente, de manera que la etapa 1904 no se realiza. En otras realizaciones AF 324 se suscribe a notificación temprana y tardía, de manera que las etapas 1904 y 1908 se realizan ambas.
En otra implementación, la reubicación de anclaje de sesión de PDU es para una sesión de PDU dedicada a una aplicación de Computación en el Borde. En este caso, el tráfico llevado por la sesión de PDU se asocia únicamente a la aplicación de Computación en el Borde. Si la SMF decide reseleccionar el anclaje de sesión de PDU para la sesión de PDU, moverá todo el tráfico asociado a la sesión de PDU a el nuevo anclaje de sesión de PDU y entonces liberará el antiguo anclaje de sesión de PDU.
La FIG. 20 es un diagrama de señalización que ilustra una realización de un método para reubicación de anclaje de sesión de PDU para una sesión de PDU dedicada a una aplicación de Computación en el Borde. Como se muestra en la FIG. 20, en la etapa 2000 el UE 102 tiene una sesión de PDU establecida con la UPF1 304A como el anclaje de sesión de p Du . La sesión de PDU se dedica para el tráfico asociado a la aplicación de Computación en el Borde. En la etapa 2002 la SMF 310 recibe un desencadenante a reseleccionar la UPF2 304B como anclaje de sesión de PDU. Esto se puede desencadenar, por ejemplo, por la reubicación de aplicación, movilidad de UE, cambio de política, etc. En la etapa 2004 la SMF 310 notifica a la AF 324 acerca de la reselección de camino de UP, si la AF 324 se ha suscrito a este tipo de notificación temprana. La notificación indica a la UPF2 304B como el nuevo anclaje de sesión de PDU. En la etapa 2006 la SMF 310 reconfigura el camino de UP con la UPF2304B como el anclaje de sesión de PDU, que incluye la configuración de enrutamiento de tráfico N6 en la UPF2304B. En la etapa 2008 la SMF 310 notifica a la AF 324 acerca de la reselección de camino de UP, si la AF 324 se ha suscrito a este tipo de notificación tardía. La notificación indica el nuevo anclaje de sesión de PDU es UPF2304B. En algunas realizaciones, AF 324 se suscribe a notificación temprana únicamente, de manera que la etapa 2008 no se realiza. En algunas realizaciones, AF 324 se suscribe a notificación tardía únicamente, de manera que la etapa 2004 no se realiza. En otras realizaciones AF 324 se suscribe a notificación temprana y tardía, de manera que las etapas 2004 y 2008 se realizan ambas. En la etapa 2010 la SMF 310 libera el recurso de sesión de PDU con UPF1 304A.
En otra implementación, la reubicación de anclaje de sesión de PDU es para una sesión de PDU compartida por múltiples aplicaciones de Computación en el Borde. En este caso, la sesión de PDU lleva tráfico asociado a múltiples aplicaciones de Computación en el Borde. Si la SMF 310 es motivada a reseleccionar el anclaje de sesión de PDU para una aplicación de Computación en el Borde, configurará una UPF como UL de Clasificador de Enlace ascendente (CL) de modo que el tráfico asociado a esa aplicación de Computación en el Borde es reenviado de la UL CL al nuevo anclaje de sesión de PDU mientras que el otro tráfico es reenviado al antiguo anclaje de sesión de PDU.
La FIG. 21 es un diagrama de señalización que ilustra una realización de un método para reubicación de anclaje de sesión de PDU para una sesión de PDU compartida por múltiples aplicaciones de Computación en el Borde. Como se muestra en la FIG. 21, en la etapa 2100, el UE 102 tiene una sesión de PDU establecida con la UPF1 304A como el anclaje de sesión de PDU para el tráfico asociado a la aplicación de Computación en el Borde. En la etapa 2102 la SMF 310 decide reseleccionar la UPF2 304B como el anclaje de sesión de PDU para el tráfico asociado a la aplicación de Computación en el Borde. Esto se puede desencadenar, por ejemplo, por la reubicación de aplicación, movilidad de UE, cambio de política, etc. En la etapa 2104 la SMF 310 notifica a la AF 324 acerca de la reselección de camino de UP, si la AF 324 se ha suscrito a este tipo de notificación temprana. La notificación indica la UPF2304B como el nuevo anclaje de sesión de PDU para el tráfico asociado a la aplicación de Computación en el Borde. En la etapa 2106 la SMF 310 configura la UPF2304B por medio de N4 para ser el nuevo anclaje de sesión de PDU para el tráfico asociado a la aplicación de Computación en el Borde. En la etapa 2108 la SMF 310 configura por medio de N4 una UPF como UL CL 304C para la sesión de PDU y prepara las dos ramificaciones desde la UL CL 304C a la UPF1 304A y la UPF2304B. La SMF 310 proporciona a la UL CL 304C las reglas necesarias de reenvío de tráfico de UL. La SMF 310 entonces ordena, en la etapa 2110, la (R)AN 302 para actualizar N3. En la etapa 2112, la SMF 310 notifica a la AF 324 acerca de la reselección de camino de UP, si la AF 324 se ha suscrito a este tipo de notificación tardía. La notificación indica la UPF2 302B como el nuevo anclaje de sesión de PDU para el tráfico asociado a la aplicación de Computación en el Borde. En algunas realizaciones, AF 324 se suscribe a notificación temprana únicamente, de manera que la etapa 2112 no se realiza. En algunas realizaciones, AF 324 se suscribe a notificación tardía únicamente, de manera que la etapa 2104 no se realiza. En otras realizaciones AF 324 se suscribe a notificación temprana y tardía, de manera que las etapas 2104 y 2112 se realizan ambas.
En algunas circunstancias, la dirección de red (p. ej. dirección IP) de una AF 324 (una aplicación de computación en el borde) conocida para el UE 102 no indica la ubicación real donde se hospeda la AF 324 (p. ej. la dirección IP puede no apuntar al servidor en el que se ejemplifica la AF). Esto puede surgir, por ejemplo, debido a movilidad de AF, y puede ser más común en un entorno virtualizado. Como resultado, la dirección IP de la AF 324 puede no trabajar en todas comunicaciones de enlace ascendente (UL) del UE 102.
En algunas realizaciones, puede emplearse gestión conjunta de la CN-UP y la DN local. Una NEF (una función de CP en CN) determina la interconexión entre UPF y hospedajes físicos de AF (es decir, aplicaciones de computación en el borde). La NEF puede determinar la interconexión en función de la información de AF proporcionada por la controlador de MEC e información preconfigurada de topología entre UPF y AF hospedajes. La NEF compila parámetros de protocolo para la interconexión entre<u>P<f>y hospedajes de AF. La compilación puede basarse en al menos una de la información de protocolo proporcionada por controlador de MEC y el UE e información de sesión proporcionada por otras CPF. La NEF ordena a la PCF generar políticas según la decisión de gestión. La decisión de gestión es por sesión/grupo de sesiones, por UE/grupo de UE, o por aplicación/servicio
Un controlador de MEC gestiona el encadenamiento de funciones de servicio dentro de la DN local y gestiona/configura hospedajes de AF para la interfaz con UPF en función de al menos una de la información de UPF e de UE proporcionada por el CN-CP La gestión es por sesión/grupo de sesiones, por UE/grupo de UE, o por aplicación/servicio.
Una SMF (una función de CP en CN) gestiona y configura el camino y protocolos entre RAN y UPF de anclaje y configura y UPF de anclaje para la interfaz con hospedajes de AF según las políticas proporcionadas por la PCF que incluyen parámetros de protocolo y destino de enrutamiento. La SMF puede además proporcionar la controlador de MEC (directamente o por medio de NEF), con información relacionada con al menos una de la UPF de anclaje y el UE. La gestión es por sesión
Haciendo referencia a la FIG. 22, se proporciona un diagrama de red simplificado que ilustra gestión segmentada. El CN-CP 328 gestiona el Cn -UP 326 y un controlador de MEC 324 gestiona la MEC en la DN local 306. La NEF 314 gestiona los enlaces entre la Cn -UP 326 y la DN local 306. Los expertos en la técnica apreciarán que los enlaces gestionados por la NEF 314 pueden entenderse como enlaces lógicos entre funciones de red en la CN-UP 326 y DN local 306.
Un UE 102 puede descubrir aplicaciones de MEC al enviar una petición de descubrimiento a una función de CP La petición puede incluir un nombre de DN local que pide descubrimiento de las aplicaciones de MEC hospedadas dentro de DN local especificada. En algunas implementaciones, la ausencia de un nombre de DN local indica que se pide un descubrimiento de todas aplicaciones de MEC. La función de CP responde al UE con el resultado de descubrimiento. El resultado de descubrimiento incluye lista de <identificador de aplicación, [dirección de aplicación]>, donde [] indica que la información es opcional. En algunas realizaciones, los resultados de descubrimiento se limitan a aquellas aplicaciones de MEC disponibles para el UE 102 o aquellas aplicaciones de MEC que el UE 102 está autorizado a usar. La dirección de aplicación es usada por el UE 102 para comunicación de capa superior (tal como capa TCP) con la aplicación de MEC. La información de aplicación de MEC puede ser mantenida por NRF 318 o almacenarse en UDM 320 o SMF 310. La función de CP puede ser cualquier función de CP relevante, que incluye por ejemplo AMF 308, NEF 314, SMF 310, NRF 318. La función de CP necesita interactuar con la NRF 318 o la u Dm 320 o SMF 310 para obtener la info de app de MEC pedida antes del reenvío al UE 102. La función de CP también puede ser la NRF 318 o la UDM 320 o SMF 310. En realizaciones donde la función de CP es AMF 308, el procedimiento de descubrimiento se puede integrar con procedimiento de registro, es decir, en el mensaje completo de registro (al UE 102), la AMF 308 puede incluir el resultado de descubrimiento.
La función de CP puede notificar al UE 102 acerca de cambios en el resultado de descubrimiento, tal como un cambio de dirección de aplicación, a través de un mensaje de NAS. El UE 102 puede presentar una petición para sesiones de PDU dedicadas para manejar tráfico asociado a aplicaciones de Computación en el Borde. Este tipo de sesión de PDU dedicada se puede usar para una única aplicación de Computación en el Borde o compartirse por múltiples aplicaciones de Computación en el Borde.
En algunas implementaciones, la petición del UE puede especificar si la sesión de PDU dedicada es para ser utilizada con una única aplicación de Computación en el Borde o compartida por múltiples aplicaciones de Computación en el Borde. En algunas implementaciones, si el UE 102 pide usar con una única aplicación de Computación en el Borde, el UE 102 puede indicar la aplicación a la SMF 310 durante el procedimiento de establecimiento de sesión de PDU. La SMF 310 puede indicar al UE 102 la dirección de la aplicación durante la etapa de aceptación de establecimiento de sesión.
La gestión conjunta resuelve la cuestión de direcciones en comunicaciones de UL. Mientras no sea requerido, usar gestión conjunta para gestión conjunto de comunicaciones de DL unión a la dirección IP de UE desacoplarse de UPF de anclajes, es decir, reselección transparente de UPF. La reselección de UPF de anclaje puede deberse a movilidad de UE, movilidad de AF, carga, etc. La dirección IP de UE no necesita cambiar conforme cambia la UPF de anclaje.
La FIG. 23 es un diagrama de flujo de mensaje que ilustra procedimientos representativos para autenticación/autorización de terceros por medio de la NEF 314. La autenticación/autorización de terceros para establecimiento de sesión de PDU es opcionalmente desencadenada por la SMF 310 durante un procedimiento de establecimiento de sesión de PDU y realizada por medio de la NEF 314.
Los expertos en la técnica apreciarán que en referencia a esta figura, y a las otras figuras de la aplicación, puede haber discusión de una función de red que desencadena un proceso. Esto debe entenderse como que incluye una función de red que transmite una petición o una notificación a otra función de red, así como que incluye una función de red que inicia un proceso interno que puede tener como resultado la transmisión de una petición o notificación a otra función de red. En referencia a una función que desencadena un proceso, el entendimiento del término "desencadenar" no debe restringirse a un significado en el que un estado de la función u otra característica de este tipo se compara con un umbral, y en respuesta a la comparación se invoca un proceso.
En la etapa 2302 la SMF envía una petición para un autenticación/autorización de terceros a la NEF 314. Como parte de esta petición, la SMF 310 puede proporcionar a la NEF 314 el Contenedor de Petición de SM PDU AF en un mensaje de petición de autenticación/autorización de terceros. El mensaje de petición puede incluir al menos una del DNN, S-NSSAI y el identificador de aplicación. El identificador de aplicación, como se describe previamente, puede ser proporcionada por el UE 102 como parte de la Petición de Establecimiento de Sesión de PDU.
En la etapa 2304 la NEF 314 selecciona una AF 324 usando la información recibida en la etapa 2302. En la etapa 2306 la NEF 314 reenvía a la AF 324 seleccionada la Contenedor de Petición de SM<p>D<u>AF recibido de la SMF 310 usando un mensaje de petición de autenticación/autorización. El mensaje de petición puede incluir además el identificador de aplicación.
Un procedimiento de autenticación/autorización 2308 tiene lugar entre el UE 102 y la AF 324 con mensajes transportados por medio de la NEF 314, la SMF 310 y NAS. En la etapa 2308a la a F transmite una petición de Autenticación/Autorización a la NEF 314. En respuesta a la Petición de Autenticación/Autorización, en la etapa 2308b la NEF 314 transmite una Transporte de NEF (Mensaje de Autenticación) a la SMF 310, donde el mensaje de Autenticación incluye información de petición de autenticación/autorización recibida de la AF 324 para el UE 102 en la etapa 2308a. En respuesta a recibir la Transporte de NEF (Mensaje de Autenticación), en la etapa 2308c la SMF 310 transmite un Transporte de NAS SM (Mensaje de Autenticación) a la AMF 314. En la etapa 2308d la AMF 324 reenvía entonces la Transporte de nAs SM (Mensaje de Autenticación) al UE 102 por medio de la (R)AN 302. En la etapa 2308e el u E 102 responde al transmitir un Transporte de NAS SM (Mensaje de Autenticación) a la AMF 308 por medio de la (R)a N 302, donde el mensaje de Autenticación está pensado para la AF 324. En la etapa 2308f la AMF 308 transmite la Transporte de NAS SM (Mensaje de Autenticación) a la SMF 310. En respuesta a recibir la Transporte de NAS SM (Mensaje de Autenticación) en la etapa 2308g la SMF 310 transmite un Transporte de SMF (Mensaje de Autenticación) a la NEF 314. En respuesta a recibir la Transporte de SMF (Mensaje de Autenticación), en la etapa 2308h la NEF 314 transmite una respuesta de Autenticación/Autorización a la AF 324. Debe entenderse que procedimientos alternativos que comprenden diferentes etapas también pueden ser adecuados para su utilización.
En la etapa 2310 la AF 324 en función del mensaje de Autenticación del UE 102 concluye la autenticación/autorización y envía un mensaje de respuesta de autenticación/autorización a la NEF 314, para confirmar la autenticación/autorización exitosa de la sesión de PDU o un fallo. La AF 324 puede proporcionar un Contenedor de Respuesta SM PDU AF a la NEF 314 para indicar autenticación/autorización exitosa o fallo. El Contenedor de Respuesta SM PDU AF puede incluir el (los) identificador(es) de aplicación(es) con los que el UE 102 se autoriza a usar la sesión de PDU.
En la etapa 2312 la NEF 314 envía un mensaje de respuesta de autenticación/autorización de terceros a la SMF 310 que contiene el Contenedor de Respuesta SM PDU AF.
La FIG. 24 es un diagrama de flujo de llamada que ilustra procedimientos representativos para establecimiento de autenticación/autorización de sesión de PDU.
En la etapa 2402 la SMF 310 selecciona una UPF 304. En la etapa 2404 la SMF 310 transmite el Contenedor de Petición SM PDU DN en un mensaje de Reenvío de Datos N4 a la UPF 304 seleccionada. En algunos casos, esto se denomina la SMF 310 "desencadena" el procedimiento de establecimiento de sesión de PDU. En una realización, la SMF 310 proporciona a la UPF seleccionada 304 configuración de direccionamiento de información de tráfico (que puede, por ejemplo, ser un mensaje de configuración detallado o un identificador que apunta a información de configuración prealmacenada accesible para la UPF). La información de configuración de direccionamiento de tráfico puede ser parte del mensaje de Reenvío de Datos N4, o puede transmitirse como mensaje separado a la UPF 304. En la etapa 2406 la UPF 304 reenvía a la DN 306 el Contenedor de Petición SM PDU DN recibido de la SMF 310.
Tiene lugar un procedimiento de autenticación/autorización 2408 y se muestra como que incluye las etapas 2408a a 2408h entre el UE 102 y la DN 306 con mensajes transportados por medio de N4 y NAS. Debe entenderse que procedimientos alternativos que comprenden diferentes etapas también pueden ser adecuados para su utilización.
En la etapa 2410, la DN confirma la autenticación/autorización exitosa de la sesión de PDU. La DN puede proporcionar un Contenedor de Respuesta SM PDU DN a la UPF para indicar autenticación/autorización exitosa.
En la etapa 2412, la UPF 304 devuelve un mensaje de Reenvío de Datos N4 a la SMF 310 que contiene el Contenedor de Respuesta SM PDU DN.
La FIG. 25A es un diagrama de flujo de mensaje que ilustra procedimientos representativos entre la Función de Aplicaciones (AF) 324 y elementos de la Red Central 5G (5GC). Estos procedimientos se pueden usar para mantener o configurar un camino de plano de usuario eficiente para flujos de tráfico asociados con aplicaciones que requieren la eficiencia de camino de plano de usuario de extremo a extremo.
En una primera etapa 2500, la AF 324 puede enviar un mensaje de petición de AF a la NEF 314. Se contempla que el mensaje de petición puede contener una pluralidad de campos, tales como, por ejemplo: Identificador de Petición; Identificador de Red de Aplicaciones; Identificador Externo de Aplicación; Filtro de Tráfico; Condición de Validez Temporal; Condición de Validez Espacial; Tipo de Petición y Contenido de Petición. El mensaje de petición de AF también puede incluir información para indicar sesiones actuales o futuras a las que se puede aplicar la petición. En algunas de tales realizaciones, un identificador de UE, un identificadores de grupo de UE, un identificador de un grupo de UE, u otra información de este tipo se puede incluir dentro de la petición de AF.
El identificador de Petición se puede usar para identificar de manera única el mensaje de petición de AF, y así puede habilitar la AF 324 para modificar o borrar el mensaje de petición de AF o para correlacionar el mensaje de petición de AF con futuros mensajes de petición de AF. El identificador de petición puede ser generado ya sea por la propia AF 324 o por la NEF 314. En realizaciones en las que la AF 324 genera el identificador de petición, se puede incluir en el mensaje de petición de AF enviado a la NEF 314, que puede grabar el identificador de petición para uso futuro. En realizaciones en las que la NEF 314 genera el identificador de petición, puede ser trasladado a la AF 324 en una mensaje de respuesta de petición de AF, que se describirá con mayor detalle a continuación.
El identificador de red de aplicaciones se puede usar para indicar la red en la que se encuentra la aplicación. En este sentido, la red en la que se encuentra la aplicación puede ser una red virtual, una red física, una red de dominio, etc. El identificador de red de aplicaciones puede ser en forma de nombre de red tal como un nombre de dominio o un nombre de red virtual.
El Identificador Externo de Aplicación se puede usar para identificar la aplicación con la que se relaciona la petición de AF.
El filtro de Tráfico se puede usar para seleccionar el tráfico al que se aplica el camino de plano de usuario. En realizaciones específicas, el filtro de tráfico puede tener cualquier combinación válida de uno o más de las siguientes formas:
identificadores de UE tales como Identificador Externo de UE o Estación Móvil ISDN (MSISDN), p. ej. para hacer referencia a tráfico futuro de UE particulares o tráfico no IP de UE particulares; direcciones IP/Prefijos, p. ej. para hacer referencia a tráfico IP asociado a sesiones de PDU en marcha; identificadores de petición de AF, p. ej. para hacer referencia a la filtros de tráfico definidos en peticiones de AF anteriores;
un indicador ANY_UE, por ejemplo para hacer referencia al tráfico de cualquier UE.
La condición de validez temporal es un parámetro opcional que se puede usar para indicar un periodo de tiempo en el que la función de petición de AF es válida. La condición de validez temporal puede incluir un conjunto de elementos de tiempo tales como: momento de inicio; momento de finalización; y frecuencia, donde la frecuencia puede, por ejemplo, indicar cada día, cada semana, cada mes, sin repetición, etc.
La condición de validez espacial es un parámetro opcional que se puede usar para indicar un área en la que el mensaje de petición de AF es válido. Por ejemplo, la condición de validez espacial se puede usar para limitar la validez del mensaje de petición de AF a la ubicación del UE actual. La condición de validez espacial puede tener la forma de uno o más identificadores de zona o dominio. La zona o dominio puede referirse a una región geográfica o un zona o dominio de red. Un zona geográfica se puede definir desde el punto de vista de una frontera geográfica (y puede combinarse con una condición de validez temporal) para aplicar a cualquier dispositivo electrónico (p. ej. un UE) dentro de la frontera definida (o a un conjunto especificado de dispositivos dentro de la frontera), o se puede definir desde el punto de vista de la topología de una red (p. ej. por especificar que el mensaje de petición se aplica a cualquier conexión a través de un conjunto de Nodos de Acceso, u otros nodos de red o funciones) en lugar de la frontera basada en coordenadas geográficas. Como se señala anteriormente la condición de validez espacial puede combinarse con otras condiciones de validez (p. ej. validez temporal o una memoria descriptiva del UE o UEs a los que se aplica la petición) de modo que la petición puede aplicarse a cualquier sesión en un margen de tiempo, donde un UE en un conjunto especificado de UE se conecta mientras que en un área espacial definida ya sea por una frontera geográfica, o definida por una restricción topológica de red (p. ej. todas sesiones, donde el UE se ha conectado a al menos uno de un conjunto de Nodos de Acceso en una Red de Acceso por Radio). En realizaciones donde la AF proporciona una condición de validez espacial en función de ubicaciones geográficas, una función de red dentro de la red conforme de 3GPP se puede usar para correlacionar la definición de frontera geográfica a un conjunto de nodos de acceso a red u otras funciones de red que corresponden a la frontera geográfica.
El parámetro de Tipo de petición se puede usar para indicar si el mensaje de petición de AF es 'Notificación de Ubicación de Aplicación', 'petición de suscripción de acontecimiento de gestión de UP', o 'petición de ago lpamiento de UE', por ejemplo. Si se desea, otros tipos de petición se pueden definir e indicar mediante el uso del parámetro de tipo de petición. En una alternativa adicional, el parámetro de tipo de petición se puede usar para indicar una combinación de dos o más tipos de petición. En tal caso, los campos requeridos para esos tipos de petición deben estar presentes en el formato de mensaje.
El contenido de petición se puede usar para proporcionar información adicional relacionada con la petición de AF. Si se desea, el contenido de petición también se puede usar para proporcionar información requerida para al menos uno de indicar y soportar dos o más tipos de petición, ya sea solo o en combinación con el parámetro de tipo de petición. En realizaciones específicas, esta información adicional puede ser dependiente del tipo de petición. Por ejemplo, en un escenario en el que el parámetro de tipo de petición indica que la petición de AF es una notificación de Ubicación de Aplicación, el contenido de petición puede incluir uno cualquiera o más de: ubicaciones potenciales de la aplicación; y respectivos requisitos de tunelización punto-a-punto N6 del camino de UP. Las ubicaciones potenciales de aplicación pueden ser en forma de direcciones de transporte (p. ej. nombre de servidor, dirección IP, etc.) dentro de la red de aplicaciones. Los requisitos de tunelización punto-a punto N6 pueden indicar un tipo de túnel (p. ej. no túnel, túnel IP, túnel IPIUDP, túnel Ethernet, etc.) y parámetros de protocolo de tunelización relacionados (tales como al menos uno de identificador/dirección de punto final de túnel y un número de puerto en la ubicación de aplicación, por ejemplo). La ausencia de requisitos específicos de tunelización punto-a-punto N6 se puede usar para implicar que se puede usar un conjunto de requisitos de tunelización predeterminados.
En algunas realizaciones, el campo contenido de petición también puede incluir un parámetro de Tipo de Acontecimiento/Notificación para permitir a un tipo de petición dado usarse juntamente con dos o más tipos de acontecimiento. Por ejemplo, en un mensaje de petición de AF que tiene un parámetro de tipo de petición indicativo de una petición "suscripción a acontecimiento de gestión de UP", el parámetro de Tipo de Acontecimiento/Notificación puede indicar si la petición es una notificación temprana o notificación tardía, o ambos. En otras realizaciones, el parámetro de Tipo de Acontecimiento/Notificación puede, por ejemplo, indicar un acontecimiento de cambio de UPF de anclaje, un acontecimiento de cambio de direccionamiento de tráfico, acontecimiento de cambio de QoS, etc. En algunas realizaciones, la AF puede responder a diferentes parámetros de Tipo de Acontecimiento/Notificación para realizar respectivas acciones diferente sen la DN local, tales como, por ejemplo, realizar configuración de tunelización, finalizar reubicación de aplicación, o ajustara aprovisionamiento de QoS.
En algunas realizaciones, el campo contenido de petición también puede incluir un parámetro de identificador de grupo. Por ejemplo, en un mensaje de petición de AF que tiene un parámetro de tipo de petición indicativo de una petición "ago lpamiento de UE", el identificador de grupo parámetro es el ID de grupo que hacer referencia al grupo de UE definido por el campo Filtro de Tráfico en la petición de AF. En algunas realizaciones, el parámetro de identificador de grupo es ausencia, y la NEF es responsable de adjudicar un identificador de grupo para el grupo de UE y proporcionarlo a la AF usando el mensaje de respuesta. El ID de grupo puede ser usado por la AF para construir filtro de tráfico para subsiguientes peticiones de AF.
En respuesta al mensaje de petición de AF, la NEF 314 puede ejecutar (en 2502) un proceso de autenticación/autorización entre la AF 324, una Función de Servidor de Autenticación (AUSF) 312 y un Repositorio de Datos de Usuario (UDR) 322 o una Función de Gestión Unificada de Datos (UDM) 320. En algunas realizaciones, el término UDR 322 también pueden entenderse que se refiere a un Repositorio de Datos Unificado que proporciona almacenamiento de datos unificado a datos de usuario y datos relacionados con aplicación tales como los requisitos de política proporcionados por la AF (p. ej. en forma de petición de AF).
En algunas realizaciones, la AF 324 puede registrarse a sí misma (usando su propia identidad) y las aplicaciones (p. ej. identificadores de aplicación, o identificadores externos de aplicación) que está gestionando con la red. Este registro también puede indicar el identificador de red de aplicaciones (o el DNN). El registro puede hacerse a través de una función de plano de gestión tal como el gestor de servicios, gestor de redes, gestor de dominio, etc. La función de gestión puede adjudicar credenciales de seguridad a la AF y puede almacenar los datos de registro y credenciales de seguridad en la Gestión Unificada de Datos (UDM) 32o o el UDR 322.
En el proceso de autenticación/autorización en la etapa 2503, la NEF 314 puede enviar al menos uno de información de identidad de AF, el identificador externo de aplicación (o el identificador de aplicación), y el identificador de red de aplicaciones (o el DNN) a la AUSF 312, que puede entonces interactuar con la UDM 320 (o UDR 322) para autenticación y autorización. La NEF 314 también pueden necesitar interactuar con la AF para obtener la información de identidad de AF, si esa información todavía no se ha proporcionado en mensaje de petición de AF, por ejemplo. Como alternativa, la NEF 314 puede proporcionar la identificador de AF a la AUSF, que puede entonces obtener la información de identidad de AF de la AF.
La AUSF 312 puede descubrir la dirección de AF a través de una Función de Repositorio de Función de Red (NF) (NRF) usando el identificador de AF a fin de comunicar con la AF. Como alternativa, la NEF puede proporcionar las direcciones de AF a la AUSF, que la NEF puede haber obtenido como parte de su comunicación con la AF en la etapa 2500. En otras realizaciones, pueden emplearse otros métodos de descubrimiento de dirección de AF.
Al finalizar el proceso de autenticación/autorización, la NEF puede devolver (en 2504) una mensaje de respuesta de petición de AF que incluye un código de resultado a la AF. El código de resultado puede indicar el resultado del proceso de autenticación/autorización. Si el resultado es un fallo, la NEF 314 puede terminar el procedimiento de petición de AF después de la etapa 2504. De otro modo, la NEF 314 puede proceder a la etapa 2506, y seleccionar una Función de Control de Políticas (PCF) 316 usando la n Rf 318. En algunas realizaciones, la PCF 316 pueden seleccionarse en función del área de servicio de la PCF. Por ejemplo, en esta etapa puede seleccionarse una PCF que tiene un área de servicio que al menos uno de cubre la DN local y solapa la condición de validez espacial en la petición de AF. En algunas realizaciones, la PCF 316 pueden seleccionarse en función del área de servicio de la DN local. Por ejemplo, todas las PCF dentro del área de servicio de la DN local pueden seleccionarse. En otro ejemplo, la<p>C<f>316 puede seleccionarse en función de la intersección del área de servicio de la PCF y la de la Dn local. En algunas realizaciones, el identificador externo de aplicación (o el identificador de aplicación) se puede usar para selección de PCF. En algunas realizaciones, la PCF 316 puede preconfigurarse en la NEF 314, en cuyo caso la etapa de selección de PCF 2506 puede omitirse.
En la etapa 2508, la NEF 314 puede procesar el mensaje de petición de AF y enviar un mensaje de petición de actualización de políticas a la PCF 316. El mensaje de petición de actualización de políticas puede incluir uno cualquiera o más de los siguientes parámetros: Identificador de Petición; DNN; identificador de aplicación; filtro de tráfico; condición de validez temporal; condición de validez espacial; tipo de petición; y contenido de petición.
El identificador de Petición se puede usar para identificar de manera única el mensaje de petición de actualización de políticas, y así puede habilitar la NEF 314 para modificar o borrar el mensaje de petición de actualización de políticas o para correlacionar el mensaje de petición de actualización de políticas con futuros mensajes de petición de actualización de políticas. El identificador de petición puede ser generado por ya sea la propia NEF 314 de por la PCF 316. En realizaciones en las que la NEF 314 genera el identificador de petición, se puede incluir en el mensaje de petición de actualización de políticas enviada a la PCF 316, que puede grabar el identificador de petición para uso futuro. En realizaciones en las que la PCF 316 genera el identificador de petición, puede ser trasladado a la NEF 314 en un mensaje de respuesta de petición de actualización de políticas, que se describirá más adelante. Preferiblemente, la NEF 314 mantiene una correlación entre el identificador de petición de actualización de políticas y el identificador de petición de AF recibido por la NEF en la etapa 2500.
El DNN puede correlacionarse desde el identificador de red de aplicaciones recibido por la NEF en la etapa 2500. Esta correlación puede preconfigurarse en la NEF 314. El identificador de red de aplicaciones también se puede usar para identificar información de control relevante tal como S-NSSAI con la que se relaciona la aplicación.
El identificador de aplicación puede correlacionarse del identificador externo de aplicación recibido por la NEF en la etapa 2500, y usarse dentro de la 5GC y por el UE 102 para identificar la información de control (p. ej. Única Información de Asistencia de Selección Segmento de Red (S-NSSAI), políticas) con la que se relaciona la aplicación. La correlación entre el identificador externo de aplicación y el identificador de aplicación puede preconfigurarse en la NEF 314.
El campo Filtro de Tráfico del mensaje de petición de actualización de políticas puede contener identificadores de petición de actualización de políticas, que pueden generarse en función o convertirse desde identificadores de petición de AF (si los hay) en el campo Filtro de Tráfico del mensaje de petición de AF recibido por la NEF. El campo filtro de tráfico también pueden contener identificadores de grupo de UE. El grupo de UE al que se refieren los identificadores puede ser creado o definido según una petición de agrupamiento de UE permeable de la AF, y la membresía de grupo se mantiene dentro de la UDM 320 (p. ej. UDR 322). El grupo de UE puede ser específico de aplicación.
La condición de validez espacial puede adoptar la forma de identificadores de nodo de RAN o identificadores de celda y cualquiera puede correlacionarse de la condición de validez espacial del mensaje de petición de AF recibido por la NEF en la etapa 2500. La correlación entre la condición de validez espacial del mensaje de petición de AF y la del mensaje de petición de actualización de políticas puede preconfigurarse en la NEF.
En un caso en el que la petición de AF es una notificación de Ubicación de Aplicación, el contenedor de contenido de petición puede incluir varios ID de Perfil de Enrutamiento y respectivos requisitos de tunelización punto-a-punto N6. Los ID de perfil de enrutamiento pueden correlacionarse desde información (tal como el identificador de red de aplicaciones, identificador externo de aplicación y ubicaciones potenciales de aplicación) contenida en el mensaje de petición de AF recibido por la NEF en la etapa 2500. Esta correlación puede preconfigurarse en la NEF por el plano de gestión (MP) directamente o a través de una función de red (NF), tal como PCF 316, UDM 320 o DSF (p. ej. UDR 322).
Como puede apreciarse, la preconfiguración de correlaciones, etc. (si la preconfiguración realizada en esta etapa o en otras etapas descritas en esta divulgación) puede ser hecha por una función de plano de gestión tal como un gestor de redes, gestor de segmentos o un gestor de servicios.
Cuando la función de plano de gestión realiza la preconfiguración, puede usar un sistema de gestión de elementos para instalar la información de preconfiguración en la función de red pretendida. En algunas realizaciones, la función de plano de gestión puede actuar como Función de Aplicaciones y realiza la preconfiguración a través de la PCF 316 o la NEF 314.
En algunas realizaciones, no se realiza preconfiguración directamente a la NF pretendida, pero en cambio a una tercera NF tal como un UDM 320 o un DSF. La NF pretendida puede obtener la información de preconfiguración de la tercera NF proactivamente (p. ej. periódicamente, o cuando necesario) o reactivamente (p. ej. al recibir de una notificación de la tercera NF). Los expertos en la técnica apreciarán que la DSF puede, en algunas realizaciones, por un UDR 322.
En algunas realizaciones, cuando una primera NF (p. ej. PCF) y una segunda NF (p. ej. NEF) van a ser preconfiguradas con la misma información (p. ej. perfiles de enrutamiento), la preconfiguración puede realizarse únicamente para la primera NF, y la segunda NF puede posteriormente obtener la información de preconfiguración de la primera NF.
En respuesta al mensaje de petición de actualización de políticas, la PCF 316 puede generar (en 2510) una o más políticas de gestión de U<p>según la información contenida en el mensaje de petición de actualización de políticas. Dependiendo del tipo de petición de política, las políticas de gestión de UP generadas pueden incluir al menos una de políticas de direccionamiento de tráfico, políticas de notificación de acontecimiento de gestión de UP y políticas de agrupamiento de UE.
Si el campo filtro de tráfico del mensaje recibido de petición de actualización de políticas contiene identificadores de petición de actualización de políticas, esos identificadores de petición de actualización de políticas pueden convertirse a correspondientes filtros de tráfico. El mensaje de petición también puede contener identificadores de grupo de UE que pueden convertirse a filtros de tráfico (o se pueden usar juntamente con otros datos para crear filtros de tráfico). Para la conversión, la PCF puede interactuar con el u Dr para obtener datos de política relacionados. Esta conversión puede realizarse antes de que la PCF aprovisiona datos de política a la UDR. Como alternativa, la conversión puede realizarse más tarde cuando la política se envía a la SMF. Realizar la conversión más tarde permite cualquier actualización/modificación a los filtros de tráfico en aquellas peticiones de actualización de política (p. ej. indicadas por los identificadores de petición de actualización de políticas) o la membresía a grupo de UE a reflejar cuando la SMF obtiene la política.
Una política de direccionamiento de tráfico puede incluir uno cualquiera o más de: un DNN, identificador de aplicación, filtro de tráfico, ID de perfil de direccionamiento de tráficos, un ID de perfil de enrutamiento, condición de validez temporal, condición de validez espacial, requisitos de tunelización punto-a-punto N6, e identificador de petición de actualización de políticas. Los ID de perfil de direccionamiento de tráfico pueden correlacionarse de los ID de perfil de enrutamiento en la petición de actualización de políticas (en la etapa 2508).
Una política de notificación de acontecimiento de gestión de UP puede incluir uno cualquiera o más de: un DNN, identificador de aplicación, filtro de tráfico, condición de validez temporal, condición de validez espacial, tipo de acontecimiento, tipo de notificación, identificador de receptor de notificación de acontecimiento (p. ej. una NEF o una AF o una PCF), e identificador de petición de actualización de políticas.
Una política de agrupamiento de UE puede incluir uno cualquiera o más de: un DNN, identificador de aplicación, filtro de UE, y el identificador de petición de actualización de políticas. En este caso, el filtro de tráfico en la petición de actualización de políticas (y petición de AF) puede servir como filtro de UE, y puede realizarse correlación/conversión al filtro de UE al menos una de en la NEF y la PCF como se ha descrito anteriormente.
Una vez se han generado las políticas de gestión de UP (o, equivalentemente, los datos de política de gestión de UP), la PCF puede seleccionar el UDR y aportar (en 2512) los correspondientes datos de política de gestión de UP al UDR seleccionado. El UDR pueden seleccionarse usando el DNN y el identificador de aplicación. La información de UE en el filtro de tráfico también se puede usar para selección de UDR, si se desea. El UDR puede notificar cualquier otra PCF que se han suscrito al acontecimiento de cambio de datos de políticas. Como alternativa, esto puede ser en función del solapamiento de uno cualquiera o más del DNN, identificador de aplicación, y condición de validez espacial (según se desee) y el área de servicio de la PCF.
Una vez se han proporcionado los datos de política a la UDR, la PCF devuelve (en 2514) un mensaje de respuesta de actualización de políticas a la NEF (o la AF) para acusar recibo de la recepción de la petición de actualización de políticas.
La PCF 316 también pueden notificar (en 2516) a cualquier SMF 310 que se ha suscrito a notificación del acontecimiento de actualización de políticas. Como alternativa, la PCF 316 puede identificar SMF pretendidas en función del solapamiento de condición de validez espacial (si la hay) y el área de servicio de la SMF y notificar a las SMF identificadas. Con la recepción de la notificación de la PCF 316, la SMF suscriptora 310 puede obtener las políticas de gestión de UP, identificar las sesiones de PDU a que las que se aplican las políticas, y aplicar las políticas a esas sesiones de PDU.
A fin de determinar si una SMF 310 se ha suscrito o no a notificación del acontecimiento de actualización de políticas, la SMF 310 puede enviar propiedades de sesión de PDU (tales como al menos una de: aplicación, DNN, dirección IP de U<e>, identificador de UE, e información de ubicación de UE) a la PCF 316, y la PCF 316 puede comprobar las propiedades de sesión de PDU contra las políticas actualizadas. La PCF 316 puede proporcionar las políticas actualizadas para las que es elegible la sesión de PDU a la SMF 310 según información disponible para ello. La SMF 310 puede además comprobar la sesión de PDU contra las políticas actualizadas usando propiedades de sesión de PDU que la PCF 310 no tiene. Así, la información que ha sido usada para comprobar la sesión de PDU por la PCF 316 no necesita proporcionarse a la SMF 310. Por ejemplo, si una condición de validez temporal es comprobada por la PCF 316, entonces la SMF310 no necesita comprobarla y así las políticas proporcionadas a la SMF no la incluirán. En una realización en la que la PCF no comprueba propiedades de sesión de PDU, toda la información se puede proporcionar a la SMF.
Si se desea, las condiciones de validez espacial pueden ser verificadas por la PCF (en este caso, la SMF necesita notificar a la PCF acerca de ubicación UE para la comprobación de condición de validez espacial) y desencadenar una actualización de políticas. En este caso, al menos una de la política de direccionamiento de tráfico y la política de notificación de acontecimiento de gestión de UP no incluye esas condiciones, puesto que la política es siempre espacialmente válida si existe.
Si se desea, las condiciones de validez temporal pueden ser verificadas por la PCF (en este caso, la PCF realiza periódicamente la comprobación de condición de validez temporal) y desencadena una actualización de políticas. En este caso, al menos una de la política de direccionamiento de tráfico y la política de notificación de acontecimiento de gestión de UP no incluye estas condiciones, puesto que la política siempre es temporalmente válida si existe.
La SMF puede mantener la política para sesiones de PDU individuales. En este caso, la política puede no incluir filtro de información de tráfico y la vinculación entre sesión de PDU y política puede ser indicada por la PCF (p. ej. la PCF comprueba la sesión de PDU contra la política y si se encuentra una coincidencia, entonces la PCF notifica a la<s>M<f>para obtener la política). La política puede contener información de filtro de tráfico. En este caso, la SMF puede comprobar el filtro de tráfico para determinar si aplicarla o no a una sesión de PDU o a qué parte del tráfico asociado a la sesión de PDU. En estos dos casos, la suscripción de SMF a la actualización de políticas puede ser una suscripción general o sesión de PDU específica.
La sesión de PDU puede someterse a múltiples políticas de direccionamiento de tráfico. La SMF selecciona cuál de las políticas de direccionamiento de tráfico aplicar. En algunas realizaciones, la SMF selecciona primero una política de direccionamiento de tráfico, entonces identifica las UPF que soportan el direccionamiento de tráfico especificado en la política (p. ej. por el ID de perfil de direccionamiento de tráficos) y realiza selección de UPF y selección de perfil de direccionamiento de tráfico. La SMF proporciona el identificador del perfil de direccionamiento de tráfico seleccionado a la UPF seleccionada. La UPF usa el identificador de perfil de direccionamiento de tráfico para identificar los parámetros de direccionamiento de tráfico en su configuración local.
En algunas realizaciones, en función de los requisitos de tunelización punto-a-punto N6 en la política de direccionamiento de tráfico, la SMF calcula la información de túnel punto-a-punto<n>6 y la configura en el anclaje de sesión de PDU. La información de túnel punto-a-punto N6 puede incluir Plantilla de Reenvío de Tráfico (TFT) para correlacionar túnel N6 a camino de UP para paquetes de DL e instrucciones de manejo de paquetes (p. ej. encabezado de protocolo de tunelización a aplicar) para paquetes de UL.
En el ejemplo de la FIG. 25A, la PCF puede seleccionarse (en 2506) en función del área de servicio de la solapamiento de PCF la condición de validez espacial en la petición de AF. La FIG. 25B ilustra una realización alternativa, en la que la PCF se selecciona en función de un DNN y un identificador de aplicación. La FIG. 25C ilustra otra realización alternativa, en la que la PCF se selecciona por la UDM (o UDR) en vez de la NEF.
Como puede verse en la FIG. 25B, el proceso de flujo de llamada (también denominado un flujo de mensaje) es ampliamente similar al de la FIG. 25A, excepto que en este caso, la etapa 2512 se omite y la etapa 2506 (selección de PCF) se sustituye por una etapa alternativa (2518), en la que la NEF 314 (o la AF 324) puede correlacionar el identificador de red de aplicaciones a un DNN y el identificador externo de aplicación a un identificador de aplicación, y proporcionar el DNN resultante e información de identificador de aplicación a la NRF 318 para seleccionar la PCF 316. La información de UE en el filtro de tráfico también se puede usar para selección de PCF. El identificador de aplicación se puede usar dentro de la 5GC y por el UE para identificar la información de control (p. ej. S-NSSAI, políticas) con la que está relacionada la aplicación. En algunas realizaciones, se seleccionan múltiples PCF y la NEF (o la AF) envía la petición de actualización de políticas a todas la PCF seleccionadas. En algunas realizaciones, la NEF 314 (o la AF 324) realiza selección de PCF seleccionando una agencia de PCF (que es función de red) y envía la petición de actualización de políticas a la agencia de PCF, que entonces la enviar a todas las<p>C<f>a las que da servicio o delega. En algunas realizaciones, las correlaciones pueden preconfigurarse en la NEF (o la AF). En algunas realizaciones, la selección de la PCF puede preconfigurarse en la NEF (o la AF), en cuyo caso la etapa de selección de PCF puede omitirse.
Haciendo referencia a la FIG.25C, en la realización alternativa ilustrada, la AF 324 y NEF 314 interactúan para realizar las etapas 2500, 2502 y 2504 como se ha descrito anteriormente con referencia a la FIG. 3A. A continuación (en 2520), la NEF 314 (o la AF 324) puede correlacionar el identificador de red de aplicaciones a un DNN y el identificador externo de aplicación a un identificador de aplicación, y usa la DNN resultante e información de identificador de aplicación para seleccionar un UDM 320. La información de UE en el filtro de tráfico también se puede usar para selección de UDM. El identificador de aplicación se puede usar dentro de la 5GC y por el UE 102 para identificar la información de control (p. ej. S-NSSAI, políticas) con la que está relacionada la aplicación. En algunas realizaciones, las correlaciones pueden preconfigurarse en la NEF (o la AF). En algunas realizaciones, la selección de la UDM puede preconfigurarse en NEF, en cuyo caso la etapa de selección UDM 2520 puede omitirse.
En la etapa 2522, la NEF 314 puede procesar el mensaje de petición de AF y enviar una mensaje de petición de Actualización de Datos de Aplicación a la UDM 320. La mensaje de petición de actualización de datos de aplicación puede incluir uno cualquiera o más de los siguientes parámetros: Identificador de Petición; DNN; identificador de aplicación; filtro de tráfico; condición de validez temporal; condición de validez espacial; tipo de petición; y contenido de petición.
El identificador de Petición se puede usar a de manera única identificar la aplicación actualización de datos petición, y así puede habilitar la NEF para modificar o borrar la petición de actualización de datos de aplicación para correlacionar la petición de actualización de datos de aplicación con futuras peticiones de actualización de políticas. El identificador de petición puede ser generado ya sea por la NEF 314 propio o por la UDM 320 (o UDR 322). En realizaciones en las que la NEF 314 genera el identificador de petición, se puede incluir en el mensaje de petición de actualización de datos de aplicación enviado a la UDM 320 (o UDR 322), que puede grabar el identificador de petición para uso futuro. En realizaciones en las que la UDM (o UDR) genera el identificador de petición, puede ser trasladado a la NEF 314 en un mensaje respuesta de actualización de datos de aplicación, que se describirá con mayor detalle más adelante. Preferiblemente, la NEF 314 mantiene una correlación entre el identificador de petición de actualización de datos de aplicación y el identificador de petición de AF recibido por la NEF 314 en la etapa 2500.
El DNN puede correlacionarse desde el identificador de red de aplicaciones recibido por la NEF en la etapa 2500. Esta correlación puede preconfigurarse en la NEF.
El identificador de aplicación puede correlacionarse del identificador externo de aplicación recibido por la NEF en la etapa 2500, y usado dentro de la 5GC y por el UE para identificar la información de control (p. ej. Único Información de Asistencia de Selección de Segmento de Red (S-NSSAI), políticas) con la que está relacionada la aplicación. La correlación entre el identificador externo de aplicación y el identificador de aplicación puede preconfigurarse en la NEF.
El campo Filtro de Tráfico del mensaje de petición de actualización de políticas puede contener identificadores de petición de actualización de políticas, que pueden generarse en función de identificadores de petición de AF (si los hay) en el campo Filtro de Tráfico del mensaje de petición de AF recibido por la NEF.
La condición de validez espacial puede adoptar la forma de identificadores de nodo de RAN o identificadores de celda y cualquiera puede correlacionarse de la condición de validez espacial del mensaje de petición de AF recibido por la NEF en la etapa 2500. La correlación entre la condición de validez espacial del mensaje de petición de AF y la del mensaje de petición de actualización de políticas puede preconfigurarse en la NEF.
En la etapa 2524, la UDM 320 (o UDR) puede devolver un mensaje Respuesta de Actualización de Datos de Aplicación a la NEF 314.
A continuación, la UDM 320 (o UDR) puede identificar cualquier PCF que se ha suscrito a actualizaciones de datos de notificación de solicitud. Como alternativa, la UDM 320 (o UDR) puede identificar cualquier PCF que tiene un área de servicio que incluye la DN local o interseca el área de servicio de la DN local. La UDM 320 (o UDR) puede entonces enviar (en 2526) correspondientes mensajes de Notificación de Cambio de Datos de Aplicación a cada PCF 316 identificada. En función de la información contenida en mensajes de notificación de Cambio de Datos de Aplicación recibido, una PCF 314 puede generar Políticas y reenviar correspondientes Notificaciones de Actualización de Políticas a SMF 310 suscriptoras, como se ha descrito anteriormente en la etapas 2510 y 2516. En algunas realizaciones, la notificación de cambo de datos de aplicación es una simple señal y no incluye el detalle de cambio, y la PCF necesita interactuar con la UDM (o UDR) para obtener el detalle de cambio y generar políticas por consiguiente.
Se observará que, en el ejemplo de la FIG. 25C, puesto que la UDM 320 se usa para seleccionar la PCF 314, la UDM 320 (o UDR) etapas de selección y notificación descritas anteriormente en 2512 y 2514 pueden omitirse.
Como puede apreciarse, una Función de Aplicaciones 324 que es de confianza para el operador puede interactuar directamente con la PCF 316. En tal caso, la AF 324 también pueden realizar el rol de la NEF en el procedimiento. La FIG. 26 ilustra un ejemplo diagrama de flujo de llamada correspondiente al ejemplo de la FIG. 25A, en el que etapas 2500, 2502 y 2504 de la FIG. 25A no se realizan o son realizadas por la AF 324, y las etapas 2506, 2508 y 2514 son sustituidas por las etapas 2600, 2602 y 2604 que son realizadas por la a F 324, pero son de otro modo idénticas a las etapas 2506, 2508 y 2514. Se apreciará que existen variantes análogas para las realizaciones de las FIGs. 25B, 25C y 27A-27B, que, por brevedad no se describen en detalle en esta descripción.
La FIG. 27A es un diagrama de flujo de llamada (también denominado un diagrama de flujo de mensaje) que ilustra un proceso para notificación de gestión de camino de UP a una AF 324. Puede apreciarse que una Función de Aplicaciones que es de confianza para el operador puede interactuar directamente con la p Cf 316. En tal caso, la AF 324 puede adoptar el rol de la NEF 314 en este procedimiento. El procedimiento de notificación de acontecimiento de gestión de UP puede realizarse al menos antes de que el acontecimiento de gestión de UP es iniciado en el plano de usuario o después de que sea completado, dependiendo del tipo de notificación.
Para las finalidades de este procedimiento, la AF puede suscribirse (en 2700) a notificaciones de acontecimiento de gestión de UP de la SMF 314 usando cualquier proceso adecuado tal como, por ejemplo, como se ha descrito anteriormente, o como presentado en un Estándar Técnico 3GPP aplicable.
En una primera etapa (en 2702) la SMF 310 puede aplicar una política de operador, e identificar (en 2704) cada NEF (o AF) que ha pedido una correspondiente notificación de actualización de políticas.
Entonces, la SMF 310 puede enviar (at2706) un mensaje de notificación de acontecimiento de gestión de UP a la (o cada) identificado NEF (o AF). El mensaje de notificación de acontecimiento de gestión de UP puede incluir uno o más de los siguientes parámetros: Identificador de Petición de Actualización de Políticas (o Identificador de Petición de Actualización de Datos de Aplicación); Filtro de Tráfico; Tipo de Acontecimiento; Tipo de Notificación; y Contenido de Notificación de Acontecimiento.
El identificador de Petición de Actualización de Políticas (o Identificador de Petición de Actualización de Datos de Aplicación) puede ser obtenido por la SMF de dentro de la política de operador.
El filtro de Tráfico puede indicar el tráfico con el que está relacionado el acontecimiento de gestión de UP, que es una parte del tráfico especificado por el campo Filtro de Tráfico en la petición de actualización de políticas. La ausencia de un Filtro de Tráfico en el mensaje de notificación de acontecimiento de gestión de UP se puede usar para indicar que el acontecimiento de gestión de UP se relaciona con todo el tráfico especificado por el filtro de tráfico en la petición de actualización de políticas. El filtro de tráfico puede incluir cualquier combinación adecuada de: identificadores de UE tales como Identificador Externo de UE o MSISSDN; y direcciones IP/Prefijos
El tipo de Notificación se puede usar para indicar si la notificación de acontecimiento de gestión de UP es una de Notificación Temprana o Notificación Tardía.
El Contenido de Notificación de Acontecimiento se puede usar para proporcionar información adicional relacionada con el acontecimiento de gestión de UP El Contenido de Notificación de Acontecimiento puede incluir uno cualquiera o más de: filtro de tráfico; ubicación de aplicación; ubicación de UPF de anclaje; e información de túnel punto-a-punto N6. La ubicación de aplicación puede adoptar la forma de un ID de perfil de enrutamiento o DNAI o ID de perfil de direccionamiento de tráfico. La ubicación de UPF de anclaje puede adoptar la forma de una dirección de red, que puede ser dependiente del tipo de túnel. Por ejemplo, para un túnel IP, es en forma de dirección IP; para un túnel Ethernet, es en forma de dirección de Ethernet. En algunas realizaciones, la información de ubicación de UPF de anclaje se puede usar para soportar la tunelización puntoa-punto N6 en la DN local. La información de túnel punto-a-punto N6 se puede proporcionar para configurarse en la ubicación de aplicación para vincular tráfico de DL con túnel punto-a-punto N6 para asegurar una entrega apropiada de paquete de DL. La información de túnel punto-a-punto N6 puede incluir al menos uno de identificador/dirección de punto final de túnel y número de puerto en el lado de UPF de anclaje. La forma del identificador/dirección de punto final de túnel puede ser dependiente del tipo de túnel. Por ejemplo, para un túnel IP, el identificador/dirección de punto final de túnel preferiblemente será en forma de dirección IP; para un túnel Ethernet, será preferiblemente en forma de dirección de Ethernet. En realizaciones específicas, la información particular proporcionada en el contenido de Notificación de Acontecimiento puede ser dependiente del tipo de acontecimiento referenciado por la notificación de acontecimiento de gestión de UP Por ejemplo, en caso de un acontecimiento de cambio de QoS, el contenido de Notificación de Acontecimiento puede incluir nuevas "reglas de QoS". En un ejemplo adicional, si el tipo de acontecimiento es cambio de direccionamiento de tráfico, entonces el contenido de Notificación de Acontecimiento puede incluir ubicación de aplicación, ubicación de UPF de anclaje, e información de túnel punto-a-punto N6.
En función del mensaje de notificación de acontecimiento de gestión de UP recibido, la NEF 314 puede enviar (en 2708) un correspondiente mensaje de notificación de acontecimiento de gestión de UP a la AF 324. El mensaje de notificación de acontecimiento de gestión de UP enviado a la AF 324 puede incluir uno cualquiera o más de: identificador de petición de AF; tipo de acontecimiento; tipo de notificación; y contenido de notificación de acontecimiento. El identificador de petición de AF puede correlacionarse desde el identificador de petición de actualización de políticas contenido en el mensaje de petición de actualización de políticas descrito anteriormente con referencia a las FIGs. 25 y 26. El contenido de notificación de acontecimiento puede correlacionarse desde el contenido de Notificación de Acontecimiento del mensaje de notificación de acontecimiento de gestión de UP recibido por la NEF de la SMF (en la etapa 2706). Por ejemplo, la ubicación de aplicación puede ser trasladada desde en forma un ID de perfil de enrutamiento o d Na I o ID de perfil de direccionamiento de tráfico a en forma de una dirección de red que se refiere a una ubicación donde la aplicación se despliega.
Tras la recepción del mensaje de notificación de acontecimiento de gestión de UP de la NEF 310, la AF 324 puede enviar (en 2710) un mensaje de acuse de recibo a la NEF 314. El acuse de recibo puede incluir información de túnel punto-a-punto N6 que se configura en la UPF de anclaje 304.
La NEF 314 puede entonces enviar (en 2712) un acuse de recibo del mensaje original de notificación de acontecimiento de gestión de UP a la SMF 310. En realizaciones en las que la AF proporciona información de túnel punto-a-punto N6 a la NEF 314, esta información se puede incluir en el mensaje de acuse de recibo enviado a la SMF 310.
Con la recepción del mensaje de acuse de recibo de la NEF 314, la SMF 310 puede configurar (en 2714) información de túnel punto-a-punto N6 en la UPF de anclaje.
Como se señala anteriormente, una Función de Aplicaciones que es de confianza para el operador puede interactuar directamente con la SMF 310. En tal caso, la AF 324 también pueden realizar el rol de la NEF 314 en el procedimiento de la FIG. 27A. Por consiguiente, las etapas 2708 y 2710 no se realizarán, y las etapas 2706 y 2712 son realizadas por la AF 324.
La FIG. 27B es un diagrama de flujo de llamada (también denominado un diagrama de flujo de mensaje) que ilustra un proceso alternativo para notificación de gestión de camino de UP a una AF 324. Como en la realización de la FIG. 27A, el acontecimiento de gestión de UP procedimiento de notificación puede realizarse al menos uno de antes el acontecimiento de gestión de UP es iniciado en el plano de usuario y después de que es completado, dependiendo del tipo de notificación.
Para las finalidades de este procedimiento, la PCF 316 puede suscribirse (en 2716) a acontecimiento de gestión de UP notificaciones de la SMF 310 usando cualquier proceso adecuado tal como, por ejemplo, como se ha descrito anteriormente, o como presentado en un Estándar Técnico 3GPP aplicable. De manera similar, la AF puede suscribirse (en 2718) a acontecimiento de gestión de UP notificaciones de la PCF 316.
En una primera etapa (en 2702) la SMF 310 puede aplicar una política de operador, e identificar (en 2720) cada PCF 316 que ha pedido una correspondiente notificación de actualización de políticas.
La SMF 310 puede enviar (en 2722) un mensaje de notificación de acontecimiento de gestión de UP a la (o cada) PCF 316 identificada. El mensaje de notificación de acontecimiento de gestión de UP puede ser formateado como se ha descrito anteriormente con referencia a la FIG. 27A.
En función del mensaje de notificación de acontecimiento de gestión de UP recibido, la PCF 316 puede enviar (en 2724) un correspondiente mensaje de notificación de acontecimiento de gestión de UP a la NEF 314. Antes de enviar el mensaje, puede convertir el ID de perfil de direccionamiento de tráfico o DNAI en el mensaje a un ID de perfil de enrutamiento. El mensaje de notificación de acontecimiento de gestión de UP enviado a la NEF 314 puede incluir uno cualquiera o más de: identificador de petición de AF; tipo de acontecimiento; tipo de notificación; y contenido de notificación de acontecimiento. El identificador de petición de AF puede correlacionarse desde el identificador de petición de actualización de políticas contenido en el mensaje de petición de actualización de políticas descrito anteriormente con referencia a las FIGs. 25 y 26. El contenido de notificación de acontecimiento puede correlacionarse desde el contenido de Notificación de Acontecimiento del mensaje de notificación de acontecimiento de gestión de UP recibido por la NEF de la SMF (en la etapa 2706). Por ejemplo, la ubicación de aplicación puede ser trasladada desde en la forma de ID de perfil de enrutamiento a en forma de una dirección de red que se refiere a una ubicación donde se despliega la aplicación. La NEF 314 puede reenviar (en 2726) el mensaje de notificación de acontecimiento de gestión de UP recibido a la AF 324.
En algunas realizaciones, el mensaje de notificación de acontecimiento de gestión de UP enviado a la NEF 314 o la PCF 316 también puede incluir un campo de formato de contenido que proporciona información acerca cómo se estructuran los datos para permitir a una función de red interpretar apropiadamente la información en el contenido de notificación de acontecimiento. Por ejemplo, el contenido de notificación de acontecimiento se puede usar para contener diferentes tipos de información (tales como ID de perfil de enrutamiento, ID de perfil de direccionamiento de tráfico, o DNAI de acontecimiento) dependiendo de la función de receptor. En tal caso, el campo de formato de contenido se puede usar para indicar el formato apropiado a usarse para leer la información en el campo de contenido de notificación de acontecimiento. El campo de formato de contenido puede establecerse por la PCF cuando es crea política, o en función del contenido de la gestión de UP uniforme notificación de la SMF (en la etapa 2722).
Tras la recepción del mensaje de notificación de acontecimiento de gestión de UP de la NEF 314, la AF 324 puede enviar (en 2728) un mensaje de acuse de recibo a la NEF 314. El acuse de recibo puede incluir información de túnel punto-a-punto N6 que se configura en la UPF de anclaje 304.
La NEF 314 puede enviar (en 2730) un acuse de recibo del mensaje de notificación de acontecimiento de gestión de UP original a la PCF 316. En realizaciones en las que la AF 324 proporciona información de túnel punto-a-punto N6 a la NEF 314, esta información se puede incluir en el mensaje de acuse de recibo enviado a la PCF 316.
Con la recepción del mensaje de acuse de recibo de la NEF 314, la PCF 316 puede reenviar (en 2732) el mensaje de acuse de recibo a la SMF 310.
Con la recepción del mensaje de acuse de recibo de la PCF 316, la SMF 310 puede configurar (en 2714) información de túnel punto-a-punto N6 en la UPF de anclaje 304.
Como se señala anteriormente, una Función de Aplicaciones que es de confianza para el operador puede interactuar directamente con la PCF 316. En tal caso, la AF 324 también pueden realizar el rol de la NEF 314 en el procedimiento de la FIG. 27B. Por consiguiente, las etapas 2726 y 2728 no se realizarán, y las etapas 2725 y 2730 se realizarían por la AF 324.
Las FIGs. 28A y 28B muestran un diagrama de flujo de llamada (también denominado un diagrama de flujo de mensaje) que ilustra un proceso para Establecimiento de Sesión de PDU pedida por UE para escenarios de no-itinerancia. El procedimiento de las FIGs. 28A y 28B asume que el UE 102 tiene ya se ha registrado en la AMF 308 así la a Mf 308 ya ha recuperado los datos de suscripción de usuario de la UDM 320.
En una primera etapa (en 2800) el UE 102 inicia el procedimiento de establecimiento Sesión de PDU pedida de UE generando y enviando un mensaje de NAS a la AMF 308. El mensaje de NAS puede comprender S-NSSAI, DNN, identificador de aplicación, ID de sesión de PDU, e información de SM N1, y puede contener una petición de Establecimiento de Sesión de PDU dentro de la información de SM N1. La Petición de Establecimiento de Sesión de PDU puede incluir un tipo de PDU, modo de SSC, y Opciones de Configuración de Protocolo. El identificador de aplicación se puede usar para describir URSP como se describe en la cláusula A.3.1.3.3 de TS 23.501.
El mensaje de NAS puede incluir un identificador de aplicación correspondiente a una aplicación de Computación en el Borde. Esto puede ocurrir, cuando el DNN apunta a una DN local. La presencia del identificador de aplicación indica que es una petición para una sesión de PDU cuyo uso es pretendido o dedicado para la aplicación de Computación en el Borde.
El mensaje de NAS enviado por el UE 102 puede ser encapsulado por la AN en un mensaje N2 que también puede incluir información de ubicación de Usuario e Información de Tipo de Tecnología de Acceso.
La información de SM puede contener Contenedor de Petición SM PDU DN que contiene información para la autorización de sesión de PDU por la DN externa.
En función de la información proporcionada en el mensaje de NAS, la AMF 308 puede determinar que el mensaje corresponde a una petición para una nueva sesión de PDU en función del ID de sesión de PDU que no se usa para cualquier sesión de PDU existente del UE. La AMF puede entonces seleccionar (en 2802) una SMF para la sesión de PDU.
En una siguiente etapa (en 2804), la AMF 308 puede enviar un mensaje de petición de SM a la SMF 310 seleccionada. El mensaje de petición puede incluir parámetros tales como: ID Permanente de Abonado, DNN, identificador de aplicación, S-NSSAI, ID de sesión de PDU, ID de AMF, información de SM N1, información de ubicación de Usuario, y Tipo de Tecnología de Acceso). El ID de AMF identifica de manera única la AMF 308 que da servicio al UE. La información de SM N1 contiene la Petición de Establecimiento de Sesión de PDU recibida del UE 102.
En función de la información proporcionada en el mensaje de petición de SM, la SMF 310 puede realizar una o más comprobaciones para determinar si el petición de UE es conforme o no con la suscripción de usuario y con políticas locales. Esto puede incluir enviar (en 2806) una petición de Datos de Suscripción a la UDM 320, y recibir (en 2808) una respuesta de Datos de Suscripción que proporciona información de la suscripción de usuario. Los datos de suscripción pueden incluir el tipo(s) de PDU autorizado(s), modo(s) de SSC autorizado(s), perfil de QoS Predeterminado, e información de grupo definida por suscripción (p. ej. Identificadores de Grupos). Si la SMF 310 todavía no ha recuperado los datos de suscripción relacionados con SM para el UE 102 relacionado con el DNN, la SMF 310 también puede pedir estos datos de suscripción de la u Dm 320.
Si la petición de UE no es conforme con la suscripción de usuario y políticas locales, entonces la SMF 310 puede rechazar la petición de UE por medio de señalización de NAS Sm para indicar a la AMF 308 que el ID de sesión de PDU tiene que considerarse liberado y el procedimiento termina.
En realizaciones en las que la SMF 310 necesita autorizar/autenticar el establecimiento de la sesión de PDU por medio de un tercero, la SMF puede desencadenar el proceso aplicable de autenticación/autorización de establecimiento de sesión de PDU de terceros 2810. El desencadenamiento del proceso de establecimiento de sesión de PDU de terceros 2810 puede incluir la SMF 310 que transmite una petición a un servicio de autenticación de terceros, que puede residir dentro de la DN. Este proceso 2810 puede ser por medio de la UPF o la NEF, como se describe en otra parte en esta divulgación. Si el establecimiento de autenticación/autorización de sesión de PDU falla, la SMF 310 puede terminar el procedimiento de establecimiento de sesión de PDU e indica un rechazo al UE 102.
En realizaciones en las que se despliega PCC dinámico, la SMF 310 puede realizar selección de PCF (en 2812). La SMF 310 también pueden iniciar establecimiento de sesión PDU-CAN (2814) con la PCF 316 para obtener las reglas de PCC predeterminadas para la sesión de PDU. En realizaciones en las que se despliega PCC dinámico y el DNN apunta a una DN local, la SMF 310 puede proporcionar el DNN y el identificador de aplicación a la PCF 316. A la p Cf 316 se le puede proporcionar información adicional para permitir decisiones de políticas más detalladas. Por ejemplo, información de UE (tal como información de ubicación, identificador de UE, información de grupo definida por suscripción, etc.) o información de tráfico (p. ej. dirección IP de UE) se puede proporcionar de modo que la PCF pueda responder únicamente con política que se adecúa a los requisitos del UE o tráfico específicos. Se puede proporcionar otra información relacionada con sesión de PDU, si se desea. La PCF puede usar esta información para obtener datos de política relevantes del UDR para decisiones de políticas. Esto puede hacer que la PCF se suscriba a notificaciones de al menos uno de cambio de datos de política relacionados con la Dn y la aplicación de la UDR. Las reglas de PCC pueden incluir notificación de acontecimiento de políticas de gestión de camino de UP Las reglas de PCC pueden incluir información de Túnel N6 relacionada con la DN (tal como al menos una de dirección y número de puerto del túnel extremo en la DN). Puede apreciarse que la finalidad de esta etapa es recibir reglas de PCC antes de seleccionar la UPF. Si reglas de PCC no son necesarias como entrada para selección de UPF, esta etapa se puede omitir.
La SMF 310 puede seleccionar (en 2816) una UPF 304 y un modo de SSC para la sesión de PDU. En realizaciones en las que el tipo de PDU es ya sea IPv4 o IPv6, la SMF 310 puede adjudicar una dirección IP/prefijo para la sesión de PDU. Para tipo de PDU no estructurada, la SMF 310 puede adjudicar un prefijo IPv6 para la sesión de PDU y tunelización punto-a-punto N6 (en función de UDP/IPv6). Si se proporcionan políticas de direccionamiento de tráfico, la SMF 310 también pueden seleccionar un perfil de direccionamiento de tráfico o política en esta etapa.
En realizaciones en las que se despliega PCC dinámico y el establecimiento de sesión PDU-CAN no se ha realizado en la etapa 2514, la SMF 310 puede iniciar (en 2818) establecimiento de sesión PDU-CAN hacia la PCF 316 para obtener las reglas de PCC predeterminadas para la sesión de PDU. Si el DNN apunta a una DN local, además de la información de UE (p. ej. identificador de UE, información de grupo definida por suscripción) la SMF 310 también puede proporcionar el DNN y el identificador de aplicación (si disponible) a la PCF 316. De otro modo, si se despliega PCC dinámico y el tipo de PDU es ya sea IPv4 o IPv6, la SMF 310 puede iniciar modificación de sesión PDU-CAN y proporcionar la dirección IP de UE/prefijo adjudicada a la PCF 316. Si se despliega PCC dinámico, para tipo de PDU no estructurado, la SMF 310 puede proporcionar el prefijo IPv6 adjudicado para la sesión de PDU a la PCF 316.
En una siguiente etapa (2820), la SMF 310 puede seleccionar una política o perfil de direccionamiento de tráfico.
En realizaciones en las que se proporcionan políticas de notificación de acontecimiento de gestión de camino de UP, la SMF puede notificar (en 622) la AF (o NEF) acerca de la selección de camino de UP Si las políticas de direccionamiento de tráfico indican una necesidad para configuración dinámica en Información de Túnel N6 entre la SMF 310 y la AF 324, la negociación también puede realizarse junto con la notificación de selección de camino de UP La notificación puede incluir información de túnel relacionada con N6 con la UPF (p. ej. al menos una de la dirección y número de puerto de la UPF) y una indicación que es una notificación temprana.
En la etapa 2824, la SMF 310 puede enviar un Establecimiento de Sesión N4/Petición de Modificación a la UPF 304 y proporcionar reglas de detección de paquetes, imposición y creación de informes a instalar en la UPF 304 para esta sesión de PDU. En realizaciones en las que el proceso de autenticación de sesión de PDU no se realiza (en 2810), el mensaje de Establecimiento de Sesión N4/Petición de Modificación se puede usar para iniciar un procedimiento de establecimiento de sesión N4 con la UPF seleccionada 308, de otro modo se puede usar para iniciar un procedimiento de modificación de sesión N4 con la UPF seleccionada 308: Si Info de Túnel CN se adjudica por la SMF, la Info de Túnel CN aplicable se proporciona a UPF 308 en esta etapa. Si Túnel N6 va a ser soportado, la Información de Túnel n 6 aplicable se proporciona a UPF 304 en esta etapa. Debe entenderse que la Información de Túnel N6 no necesariamente tiene que proporcionarse a la UPF 304 en esta etapa.
La UPF puede acusar recibo del mensaje de Establecimiento de Sesión N4/Petición de Modificación al enviar (en 2826) un mensaje de Establecimiento de Sesión N4/Respuesta de Modificación a la SMF. Si Info de Túnel CN es adjudicada por la UPF 308, la Info de Túnel CN aplicable también puede proporcionarse a SMF 310 en esta etapa.
En la etapa 2828, la SMF 310 puede devolver un mensaje de Acuse de Recibo de Petición SM a la AMF 308. El mensaje de Acuse de Recibo de Petición SM puede contener parámetros tales como: Información de SM N2 (p. ej. ID de sesión de PDU, Perfil de QoS, y Info de Túnel CN); información de SM N1 (p. ej. Aceptación de Establecimiento de Sesión de PDU (que incluye Regla de QoS Autorizada y modo de SSC)). La información SM N2 puede llevar información que la AMF 218 tiene que proporcionar a la (R)AN. La Info de Túnel CN puede corresponder a la dirección Red Central del túnel N3 correspondiente a la sesión de PDU. El perfil de QoS puede proporcionar a la AN la correlación entre parámetros de QoS e Identificadores de Flujo de QoS. El ID de sesión de PDU puede ser usado por señalización de AN con el UE para indicar al UE la asociación entre recursos de AN y una sesión de PDU para el UE. La información de SM N1 puede contener el mensaje de Aceptación de Establecimiento de Sesión de PDU que la AMF necesita proporcionar al UE. Múltiples Reglas de QoS Autorizado se pueden incluir en el mensaje de Aceptación de Establecimiento de Sesión de PDU dentro de la información de SM N1 y en la información de SM N2.
El mensaje de Acuse de recibo de Petición de SM puede además contener información que permite a la AMF identificar qué UE es el objetivo de la petición de SMF además de determinar qué acceso hacia el UE usar. La información de acceso se puede usar para tratar con el caso en el que un UE se conecta simultáneamente por acceso 3GPP y no 3GPP
Haciendo referencia ahora a la FIG. 28B, en la etapa 2830, la AMF puede enviar un mensaje de Petición de Sesión de PDU N2 a la R(AN) 302. El mensaje de Petición de sesión de PDU N2 puede contener parámetros tales como: información de SM N2; y Aceptación de Establecimiento de Sesión de PDU.
En respuesta al mensaje de Petición de Sesión de PDU N2, la R(AN) 302 puede iniciar (en 2832) intercambio de señalización específico de AN con el UE 102 para configurar recursos para la sesión de PDU. Por ejemplo, en caso de un RAN 3GPP, puede tener lugar una Reconfiguración de Conexión RRC con el Ue 102 estableciendo los recursos RAN necesarios relacionados con las reglas de QoS Autorizada para la sesión de PDU. Nodos dentro de la (R)AN también pueden adjudicar información de túnel de (R)AN para la sesión de PDU. Los nodos de (R)AN pueden reenviar el mensaje de NAS (que incluye la Aceptación de Establecimiento de Sesión de PDU) al UE, si los recursos de RAN necesarios se establecen y la adjudicación de información de túnel de (R)AN son exitosos.
Tras la preparación de los recursos para la sesión de PDU, el nodo de (R)AN 302 puede enviar (en 2834) un Mensaje de acuse de recibo de petición de sesión de PDU N2 a la AMF 308. El mensaje de Acuse de Recibo de Petición de Sesión de PDU N2 también puede incluir información de túnel de (R)AN correspondiente a la Dirección de Red de Acceso del túnel N3 para a la sesión de PDU. Tras la recepción del mensaje de acuse de recibo de petición de sesión de PDU N2 por la AMF 304, el UE 102 puede ser capaz de comenzar a transmitir (en 2836) datos de Enlace ascendente de la sesión de PDU a la UPF 304.
En una siguiente etapa (2838), la AMF 308 puede reenviar la información de SM N2 recibida de (R)AN a la SMF 310, usando un Mensaje de petición SM que incluye la información de SM N2.
A continuación, la SMF 310 puede enviar (en 2840) una petición modificación de sesión N4 a la UPF 304 con el fin de proporcionar Info de Túnel AN y (opcionalmente) Info de Túnel CN para la sesión N4 asociada con la nueva sesión de PDU. En un caso en el que la sesión N4 para la nueva sesión de PDU todavía no se ha establecido, la SMF 310 puede iniciar un procedimiento de establecimiento de sesión N4 con la UPF 304 para establecer la sesión N4 con la Info de Túnel AN y (opcionalmente) Info de Túnel CN. De otro modo, la SMF 310 puede iniciar un procedimiento de modificación de sesión N4 con la UPF 304 para añadir la Info de Túnel AN y (opcionalmente) Info de Túnel CN a la sesión N4 existente. Obsérvese que la Info de Túnel CN únicamente tiene que proporcionarse si la SMF 310 ha seleccionado Info de Túnel CN en la etapa 2816.
Tras la recepción de la Respuesta de Establecimiento de Sesión N4/Modificación de la UPF (en 2842), la SMF 310 puede notificar (en 2844) a la AF 324 (o NEF 314) acerca de la selección de camino de UP, si se proporcionan políticas de notificación de acontecimiento de gestión de camino de UP e indicar la necesidad de notificación tardía. La notificación puede incluir información de túnel relacionada con N6 con la UPF (p. ej. al menos una de la dirección y número de puerto de la UPF) y una indicación que esta es una notificación tardía. Si va a usarse Túnel N6, esta etapa puede indicar a la AF que el túnel N6 está preparado para uso. Posteriormente, la AMF puede reenviar acontecimientos relevantes a la SMF, por ejemplo en traspaso donde cambia la Información de Túnel de (R)AN o se reubica la AMF.
La SMF 310 entonces devuelve (en 2846) un Acuse de Recibo de Petición de SM a la AMF 308 antes de generar y enviar (en 2848) un Anuncio de Rúter IP al UE 102 por medio de la sesión N4 y la UPF 304. Esta etapa proporciona la información de configuración de IP de modo que se pueden transmitir Datos de Enlace descendente al UE (en 2850).
Durante la vida útil de la sesión de PDU, la AMF 308 almacena una asociación del ID de sesión de PDU y el ID de SMF.
Las FIGs. 29A y 29B muestran un diagrama de flujo de llamada que ilustra un proceso para Establecimiento de Sesión de PDU pedida por UE para itinerancia con ruptura local. El procedimiento de las FIGs. 29A y 29B es estrechamente similar al de las FIGs. 28A y 28B, excepto que en caso de itinerancia con ruptura local, la SMF 310, UPF 304 y la PCF 316 se ubican todas en la red visitada. Esto implica que las etapas 2820, 2822 y 2844 descritas anteriormente no se realizan.
La FIG. 30 es un diagrama de flujo que ilustra un proceso de trasferencia según una realización de ejemplo de la presente invención. Se entenderá bien que en los diagramas de flujo ilustrados diferentes entidades son responsables de llevar a cabo diferentes etapas. Además debe entenderse que esto muestra la interacción de múltiples métodos independientes cada uno de los cuales se lleva a cabo en un nodo o función diferente. Un variación de uno de los métodos no necesariamente requerirá un cambio en el otro método. Es más, donde se hace referencia a una primera función que envía un mensaje a una segunda función, debe entenderse que esto implica que la segunda función realiza la etapa de recibir el mensaje transmitido por la primera función.
En una primera etapa (3000) una AF puede suscribirse a notificación de acontecimientos de movilidad de UE para algún tráfico particular asociado con una aplicación. Los acontecimientos de movilidad de UE pueden, por ejemplo, incluir el UE saliendo del área de servicio de la DN local actual.
Posteriormente, una AMF puede detectar el acontecimiento de movilidad de UE (en 3002), y envía una correspondiente notificación a la AF (en 3004). Como alternativa, la AMF puede notificar a la SMF, y la SMF a su vez notifica a la AF. La notificación puede enviarse por medio de la NEF (p. ej. cuando la a F no es de confianza) o directamente a la AF (p. ej. cuando la AF está en el dominio de confianza). La notificación puede incluir las DN locales pretendidas (donde la aplicación también se despliega) a la que se está moviendo el UE.
Con la recepción de la notificación, la AF puede identificar (en 3006) una segunda AF que se asocia con la aplicación en una DN pretendida, y notifica a la segunda AF sobre el identificador de aplicación, el filtro de tráfico (que indica el tráfico de aplicaciones impactado) y la información de contexto de aplicación. La AF puede opcionalmente notificar a la segunda AF sobre el identificador de notificación de AMF (llevado en la notificación de AMF).
La segunda AF puede entonces enviar una petición (en 3012) a la 5GC (p. ej. la SMF) para desencadenar establecimiento de sesión de PDU o reanudación después de que el UE entra en la DN local pretendida. La petición enviada a la 5GC (p. ej. la SMF) para establecimiento de sesión de PDU o reanudación puede incluir al menos uno del identificador de notificación de AMF y el filtro de tráfico, de modo que la 5GC puede retomar la sesión de PDU correcta o informar al UE para establecer sesiones de PDU para el tráfico apropiado.
Una vez ha ocurrido la movilidad de UE acontecimiento, la AMF puede enviar una correspondiente notificación a la SMF (en 3008), y la SMF puede responder desactivando o liberando (en 3010) la sesión de PDU asociada con la aplicación.
En algunos casos, la misma AF puede asociarse con la aplicación en ambas DN actual y pretendida. En este caso, la "AF" y la "segunda AF" referenciadas anteriormente son de hecho la misma entidad. En consecuencia, la interacción entre las dos AF en la etapa 3006 se convierte en un procedimiento interno, y la etapa 3012 puede ser llevada a cabo por el mensaje de respuesta desde la primera AF a la AMF o a la SMF.
Como puede apreciarse, el proceso de la FIG. 30 permite la sesión de aplicación del UE a preservar, porque el contexto de aplicación se transfiere a la segunda AF, que controla la aplicación en la DN pretendida.
En algunas realizaciones, la AF es un servidor de aplicaciones. En otras realizaciones, la AF no es un servidor de aplicaciones, pero en cambio funciona para configurar el contexto de aplicación en el servidor de aplicaciones para retomar/preservar sesiones de aplicaciones.
En algunas realizaciones, la AF es un controlador de SDN que funciona para configurar reglas de reenvío en la red de transporte para asegurar entrega de paquete a UPF correcta.
En algunas realizaciones, la aplicación es una aplicación de retransmisión de vídeo y la información de contexto de aplicación describe cómo (desde donde) retomar la retransmisión de vídeo discontinuado. En algunas realizaciones, la aplicación es una aplicación de juegos y la información de contexto de aplicación describe cómo (desde donde) reconstruir o recuperar el contexto de juegos.
El DNAI es un identificador que apunta a un nodo o función que proporciona acceso a la DN para plano de tráfico de usuario. n nodo o función en el UP que transmite tráfico a la DN, puede dirigir el tráfico a DNAI. En algunas realizaciones, el DNAI puede ser un elemento de red tal como rúter que es desplegado estratégicamente por el operador, en otras realizaciones el DNAI puede ser función de pasarela que proporciona acceso a un centro de datos dentro del que se ejemplifican UPF virtuales. Una ubicación de aplicación se refiere a un elemento de red (p. ej. un servidor, un centro de datos) en el que se despliega la aplicación. Múltiples aplicaciones se pueden desplegar en la misma ubicación.
Debe entenderse que cuando una aplicación se comunica con un UE a través de una red conforme con 3GPP, la ubicación de aplicación se puede correlacionar o asociar con un DNAI. En algunas realizaciones, esta asociación puede ser parte del perfil de enrutamiento (p. ej. almacenado o indicado de otro modo dentro del perfil de enrutamiento). En otras realizaciones la asociación es externa al perfil de enrutamiento, y puede almacenarse dentro de una tabla accesible localmente, o en un punto de referencia común dentro de la red. En algunas realizaciones el perfil de enrutamiento describe los parámetros de enrutamiento asociados con el enrutamiento de tráfico a la ubicación de aplicación. Esto puede adoptar la forma de una combinación de uno o ambos de una dirección de destino y un número de puerto de destino en la ubicación de aplicación. Tales realizaciones son ejemplos de situaciones en las que la asociación puede ser externa al perfil de enrutamiento. Los expertos en la técnica entenderán que los perfiles de enrutamiento pueden, en algunas realizaciones, ser específicos de ubicación de aplicación. Esto permite al tráfico ser dirigido al DNAI, y desde donde será reenviado a la aplicación. Una aplicación puede ejemplificarse en diferentes DN. Dentro de la misma DN, una aplicación puede ejemplificarse en múltiples ubicaciones, y cada ubicación de aplicación puede asociarse con una pluralidad de DNAI. En implementaciones donde un perfil de enrutamiento es específico por ubicación de aplicación, el perfil de enrutamiento puede indicar una dirección de transporte tal como dirección IP y número de puerto o una dirección de red tal como dirección de Ethernet, asociada con la ubicación de aplicación y otros parámetros de enrutamiento de tráfico para usarse por los DNAI asociados con la ubicación de aplicación para enrutar tráfico a la ubicación de aplicación.
En algunas realizaciones, ambos perfiles de enrutamiento y la asociación entre el perfil de enrutamiento (o la correspondiente ubicación de aplicación) y el DNAI se puede configurar en la NEF, por otra función de red (p. ej. la AF) en coordinación con la NEF o por una función de plano de gestión, tal como gestor de redes, gestor de segmentos, gestor de servicios, etc. en realizaciones en las que la AF está dentro de un de dominio de confianza, el perfil de enrutamiento y la asociación entre el perfil de enrutamiento y el DNAI se puede configurar en la propia A<f>.
Como un DNAI identifica un punto de acceso de red de datos, y cada DN puede soportar una pluralidad de aplicaciones y UPF diferentes, un DNAI puede asociarse con una pluralidad de UPF diferentes. El perfil de direccionamiento de tráfico se asocia típicamente con el DNAI y entonces se aplica a cada UPF asociada con el DNAI. En algunas realizaciones la PCF se puede configurar con la información del DNAI y los perfiles de direccionamiento de tráfico. En algunas realizaciones, la asociación entre el perfil de direccionamiento de tráfico y las UPF se puede configurar en la SMF. En otra realización, el perfil de direccionamiento de tráfico se puede configurar en la UPF y la SMF. La configuración descrita anteriormente puede ser realizada por una función de plano de gestión tal como gestor de redes, gestor de segmentos, gestor de servicios, etc. Otras funciones de red, que incluye la SMF, la NEF o la PCF, también pueden tener roles en la configuración de la UPF y el perfil de direccionamiento de tráfico. En implementaciones en las que un perfil de direccionamiento de tráfico es específico de DNAI, el perfil de direccionamiento de tráfico puede indicar una dirección de transporte tal como dirección IP y número de puerto o una dirección de red tal como dirección de Ethernet, asociada con el DNAI y otros parámetros de enriam iento de tráfico para usarse por las UPF asociadas con el DNAI para enrutar tráfico al DNAI. El perfil de direccionamiento de tráfico también puede indicar el propio DNAI por medio de un identificador.
La FIG. 31 es un diagrama de bloques lógico 3100 que ilustra una relación de ejemplo entre ubicación de aplicación, DNAI y UPF. Se ilustra un conjunto de cuatro UPF, UPF1 3102, UPF2 3104, UPF3 3106, y UPF4 3108. Se ilustra un conjunto de dos ubicaciones de aplicaciones, AS1 3120 y AS23126. El acceso a a S13120 puede ser a través ya sea de DNAI 13110 o DNAI 23114. El acceso a AS2 3126 es a través de DNAI 23114. El tráfico desde UPF1 3120 y UPF23104 a AS1 3120 se somete a perfil de direccionamiento de tráfico 13112 y perfil de enriam iento 13122. El tráfico desde UPF23104, UPF33106 y UPF43108 a AS2 3126 se somete a perfil de direccionamiento de tráfico 23116 y perfil de enrutamiento 23124. Así, tráfico desde la UPF23104 puede someterse a diferentes perfiles de direccionamiento de tráfico en función de la ubicación de aplicación pretendida.
El perfil de enrutamiento 13122 corresponde a la ubicación de aplicación AS1 3120, que se asocia con ambos DNAI1 3110 y DNAI23114. El perfil de enrutamiento 23124 corresponde a la ubicación de aplicación AS21326, que se asocia con DNAI23114.
La asociación entre una UPF y un DNAI puede implicar que la UPF puede soportar direccionamiento de tráfico hacia el DNAI usando la información especificada en el perfil de direccionamiento de tráfico asociado con el DNAI. Por ejemplo, UPF23104 se asocia con ambos DNAI1 3110 y DNAI23112. Como tal, la UPF23104 es capaz de direccionar tráfico hacia ambos DNAI.
Una correlación de información configurada en NEF, PCF y SMF se ilustra a continuación:
@ NEF: Ubicación de aplicación <— > ID de perfil de enrutamiento
@ PCF: ID de perfil de enrutamiento ^ D<n>A<i>;
DNAI <— > ID de perfil de direccionamiento de tráfico
@ SMF: ID de perfil de direccionamiento de tráfico ^ UPF
La PCF no necesita saber necesariamente el contenido de perfiles de enrutamiento y de manera similar la SMF no necesita saber necesariamente el contenido de perfiles de direccionamiento de tráfico.
En las realizaciones ilustradas de la FIG. 31, hay un conjunto mínimo de información que está disponible para cada uno de los diferentes tipos de funciones de red. Una AF debe tener acceso a la ubicación de Aplicación (p. ej. desde el punto de vista de una dirección de transporte o dirección de red de la ubicación de aplicación). El DNAI debe tener acceso a perfiles de enrutamiento asociados con la ubicación de aplicación con la que se asocia. Una UPF debe tener acceso a perfiles de direccionamiento de tráfico de los DNAI con los que se asocia. La configuración de estos nodos y funciones de modo que están provistos de esta información, o provistos con acceso a esta información, se puede realizar por cualquiera de varias funciones de plano de gestión diferentes, dicho al menos uno de como gestor de redes, gestor de segmentos, gestor de servicios y la AF. Por ejemplo, la AF puede proporcionar la información necesaria al DNAI, mientras que una función de plano de gestión proporciona la información necesaria a la NEF, la PCF, la SMF y la UPF.
Información de Túnel N6, que puede haber sido proporcionada por la SMF, se usa por una UPF para establecer un túnel N6, y para determinar el procesamiento aplicado a paquetes de UL enviados a través del túnel N6. La Información de Túnel N6 puede incluir tipo de túnel tal como túnel IP, túnel Ethernet, túnel IPv6/UDP, etc. Puede incluir información de dirección o identificador de punto final de túnel, número de puerto y otros parámetros de protocolo de túnel. Los parámetros de direccionamiento de tráfico se pueden obtener usando un ID de perfil de direccionamiento de tráfico (que por sí mismo puede obtenerse de una función tal como la SMF). Los parámetros de direccionamiento de tráfico pueden obtenerse de una configuración local. Si los parámetros de direccionamiento de tráfico no se preconfiguran localmente en la UPF, la UPF puede obtenerlos de una función tal como la SMF. Si los parámetros de direccionamiento de tráfico son proporcionados por la SMF a la UPF, el ID de perfil de direccionamiento de tráfico puede no proporcionarse a la UPF por la SMF. Los paquetes enviados a través del túnel N6 pueden encapsularse, e información de direccionamiento de tráfico puede incrustarse dentro del encabezado exterior. El encabezado exterior también puede incluir un identificación del procesamiento a aplicar para paquetes de UL.
Como se entenderá, la manera en la que tráfico en el UP se enruta y procesa puede ser configurada por funciones de CP. Para enrutamiento de tráfico influenciado por aplicación, el proceso de configuración puede comenzar con una AF que realiza un procedimiento de petición para enviar una notificación de Ubicación de Aplicación a la red. La AF puede proporcionar una ubicación de aplicación (p. ej. en una dirección de transporte) e Información de Túnel n 6 (si la hay) a la NEF. La NEF puede correlacionar la ubicación de aplicación, recibida de la AF, a un perfil de enrutamiento. La NEF puede entonces enviar el ID de perfil de enrutamiento y la Información de Túnel N6 a la PCF. La PCF puede correlacionar el ID de perfil de enrutamiento a al menos un DNAI. El ID de perfil de enrutamiento también puede correlacionarse a perfiles de direccionamiento de tráfico, por ejemplo, por medio del correlacionado al menos un DNAI. En función de estas correlaciones se puede generar una política de direccionamiento de tráfico. La política de direccionamiento de tráfico típicamente especificará uno o múltiples ID de perfil de direccionamiento de tráfico, un ID de perfil de enrutamiento e Información de Túnel N6. La política de direccionamiento de tráfico también puede contener otra información tal como condiciones de validez.
Para tráfico no IP, típicamente se requiere Información de Túnel N6. Para tráfico IP, puede ser opcional. Si no se usa Túnel N6 cuando se maneja tráfico IP, los parámetros de enrutamiento de tráfico en perfil de direccionamiento de tráfico y perfil de enrutamiento juntos puede describir cómo dirigir tráfico de principio a fin sobre N6.
Ahora se discute un ejemplo de ejecutar influencia de aplicación en enrutamiento de tráfico durante un procedimiento de establecimiento de sesión (o un procedimiento de modificación de sesión). El proceso puede comenzar con la PCF que envía una política de direccionamiento de tráfico a SMF. La SMP puede entonces correlacionar los ID de perfil de direccionamiento de tráfico (típicamente contenidos en la política de direccionamiento de tráfico, pero opcionalmente proporcionados junto con la política) a las UPF. La PCF puede entonces realizar un proceso de selección de UPF/direccionamiento de tráfico, y proporcionar el ID de perfil de direccionamiento de tráfico seleccionado y la Información de Túnel N6 (llevada por la política) a una UPF seleccionada para la sesión de PDU. La SMF puede compilar/procesar la Información de Túnel N6 antes de enviarla a la UPF, por ejemplo, generando un encabezado de túnel para que la UPF la aplique a paquetes de UL. La SMF también pueden generar una plantilla de Reenvío de Tráfico. La TFT puede ser usada por la UPF para correlacionar un Túnel N6 a un camino en el UP para tráfico de DL.
La SMF puede enviar una notificación a la NEF de cualquier cambio de Túnel N6 (p. ej. cambio de punto final de túnel N6 debido a reselección de UPF). La SMF también puede enviar una notificación a la NEF para informar a la NEF de un cambio de direccionamiento de tráfico, que puede incluir cambios en al menos una de correlaciones de DNAI e ID de perfil de enrutamiento. La NEF puede correlacionar el DNAI a una dirección de transporte y el ID de perfil de enrutamiento a una dirección de tráfico de la respectiva ubicación de aplicación. La NEF puede entonces proporcionar la información asociada con un cambio de Túnel N6 y cambio de direccionamiento de tráfico (después de correlación de información) a la AF.
Aunque la presente invención se ha descrito con referencia a características específicas y realizaciones de la misma, es evidente que se pueden realizar diversas modificaciones y combinaciones a la misma sin apartarse de la invención. Por consiguiente, la memoria descriptiva y los dibujos deben considerarse simplemente como una ilustración de la invención tal como se define en las reivindicaciones adjuntas, y se contempla que cubran cualquiera y todas modificaciones, variaciones, combinaciones que se encuentren dentro del alcance de las reivindicaciones anexas.

Claims (15)

REIVINDICACIONES
1. Un método que comprende:
recibir (308), por parte de una PCF, un mensaje de petición de actualización de políticas que incluye un contenido de petición, en donde el contenido de petición incluye ubicaciones potenciales de aplicación y respectivos requisitos de tunelización punto-a-punto N6; y
notificar (316), por parte de la PCF, una SMF de una política de direccionamiento de tráfico actualizada para configurar un anclaje de sesión de PDU, la política de direccionamiento de tráfico actualizada incluye los requisitos de tunelización punto-a-punto N6 e indica ubicaciones potenciales de aplicación asociadas con los requisitos de tunelización punto-a-punto N6.
2. El método según la reivindicación 1, en donde los requisitos de tunelización punto-a-punto N6 indican un tipo de túnel y parámetros de protocolo de tunelización relacionados.
3. El método según la reivindicación 2, en donde los parámetros de protocolo de tunelización incluyen uno o más de: una dirección de punto final de túnel, un identificador de punto final de túnel, y un número de puerto en la ubicación de aplicación.
4. El método según una cualquiera de las reivindicaciones 1 a 3, en donde el contenido de petición es recibido por la PCF desde una AF.
5. El método según cualquiera de las reivindicaciones 1 a 4, en donde la SMF es que se ha suscrito a notificación de un acontecimiento de actualización de políticas.
6. El método según una cualquiera de las reivindicaciones 1 a 5, que comprende además:
verificar, por parte de la PCF, una condición de validez espacial incluida en la petición de actualización de políticas en función de información de ubicación de UE; y
actualizar, por parte de la PCF, una política de direccionamiento de tráfico en función de un resultado de la verificación.
7. Un método que comprende:
recibir, por parte de una SMF de una PCF, una política de direccionamiento de tráfico que incluye requisitos de tunelización punto-a-punto N6;
calcular, por parte de la SMF, información de túnel punto-a-punto N6 en función de los requisitos de tunelización punto-a-punto N6; y
configurar, por parte de la SMF, la información de túnel punto-a-punto N6 en un anclaje de sesión de PDU.
8. El método según la reivindicación 7, en donde los requisitos de tunelización punto-a-punto N6 indican uno o más de un tipo de túnel y parámetros de protocolo de tunelización relacionados.
9. El método según la reivindicación 7 o 8, la información de túnel punto-a-punto N6 incluye uno o más de: plantilla de Reenvío de Tráfico, TFT, para correlacionar un túnel N6 a un camino de UP para paquetes de DL, e instrucciones de manejo de paquetes para paquetes de UL.
10. Un método, que comprende:
recibir (308), por parte de una PCF, un mensaje de petición de actualización de políticas que incluye un contenido de petición, en donde el contenido de petición incluye ubicaciones potenciales de aplicación y respectivos requisitos de tunelización punto-a-punto N6;
notificar (316), por parte de la PCF, una SMF de una política de direccionamiento de tráfico actualizada para configurar un anclaje de sesión de PDU, la política de direccionamiento de tráfico actualizada incluye los requisitos de tunelización punto-a-punto N6 e indica ubicaciones potenciales de aplicación asociadas con los requisitos de tunelización punto-a-punto N6;
recibir, por parte de la SMF de una PCF, la política de direccionamiento de tráfico actualizada; calcular, por parte de la SMF, información de túnel punto-a-punto N6 en función de los requisitos de tunelización punto-a-punto N6; y
configurar, por parte de la SMF, la información de túnel punto-a-punto N6 en un anclaje de sesión de PDU.
11. El método según la reivindicación 10, en donde los requisitos de tunelización punto-a-punto N6 indican un tipo de túnel y parámetros de protocolo de tunelización relacionados.
12. El método según la reivindicación 11, en donde los parámetros de protocolo de tunelización incluyen uno o más de: una dirección de punto final de túnel, un identificador de punto final de túnel, y un número de puerto en la ubicación de aplicación.
13. El método según una cualquiera de las reivindicaciones 10 a 12, en donde el contenido de petición es recibido por la PCF desde una AF.
14. Un aparato, configurado para realizar el método según una cualquiera de las reivindicaciones 1 a 13.
15. Un soporte de almacenamiento legible por ordenador que almacena instrucciones, cuando son ejecutadas por uno o más procesadores, provocan que el uno o más procesadores realicen un método según al menos una de las reivindicaciones 1-13.
ES23220690T 2017-01-05 2018-01-05 Application-friendly protocol data unit (pdu) session management Active ES3026565T3 (en)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
US201762442857P 2017-01-05 2017-01-05
US201762455368P 2017-02-06 2017-02-06
US201762459985P 2017-02-16 2017-02-16
US201762473274P 2017-03-17 2017-03-17
US201762477384P 2017-03-27 2017-03-27
US201762487960P 2017-04-20 2017-04-20
US201762491529P 2017-04-28 2017-04-28
US201762522040P 2017-06-19 2017-06-19
US15/832,103 US10531420B2 (en) 2017-01-05 2017-12-05 Systems and methods for application-friendly protocol data unit (PDU) session management

Publications (1)

Publication Number Publication Date
ES3026565T3 true ES3026565T3 (en) 2025-06-11

Family

ID=62711494

Family Applications (1)

Application Number Title Priority Date Filing Date
ES23220690T Active ES3026565T3 (en) 2017-01-05 2018-01-05 Application-friendly protocol data unit (pdu) session management

Country Status (9)

Country Link
US (4) US10531420B2 (es)
EP (3) EP3755012B1 (es)
JP (3) JP6848054B2 (es)
KR (1) KR102167343B1 (es)
CN (4) CN118450540A (es)
BR (1) BR112019006086A2 (es)
ES (1) ES3026565T3 (es)
RU (1) RU2758457C2 (es)
WO (2) WO2018127148A1 (es)

Families Citing this family (358)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE500698T1 (de) 2004-04-30 2011-03-15 Research In Motion Ltd System und verfahren zur filterung von datentransfers in einem mobilgerät
US9161226B2 (en) 2011-10-17 2015-10-13 Blackberry Limited Associating services to perimeters
US11477694B1 (en) * 2021-08-27 2022-10-18 Dish Wireless L.L.C. User plane function (UPF) load balancing based on central processing unit (CPU) and memory utilization of the user equipment (UE) in the UPF
US11818607B2 (en) 2011-10-26 2023-11-14 Dish Network Technologies India Private Limited Apparatus systems and methods for proximity-based service discovery and session sharing
US9936351B2 (en) 2011-10-26 2018-04-03 Sling Media Pvt Ltd Apparatus systems and methods for proximity-based service discovery and session sharing
US9613219B2 (en) * 2011-11-10 2017-04-04 Blackberry Limited Managing cross perimeter access
US9369466B2 (en) 2012-06-21 2016-06-14 Blackberry Limited Managing use of network resources
WO2018006017A1 (en) * 2016-07-01 2018-01-04 Idac Holdings, Inc. Methods for supporting session continuity on per-session basis
US10929202B2 (en) * 2016-09-16 2021-02-23 Oracle International Corporation Cloud service notifications
US10652784B2 (en) * 2016-09-30 2020-05-12 Huawei Technologies Co., Ltd. Method and apparatus for serving mobile communication devices using tunneling protocols
CN114598753B (zh) * 2017-01-09 2024-10-29 交互数字专利控股公司 用于不同通信架构之间互通的服务质量管理
US10448239B2 (en) * 2017-02-06 2019-10-15 Qualcomm Incorporated Mechanism to enable optimized user plane anchoring for minimization of user plane relocation due to user equipment mobility
JP2020057834A (ja) * 2017-02-07 2020-04-09 シャープ株式会社 端末装置、コアネットワーク装置、及び通信制御方法
CN108419270B (zh) * 2017-02-10 2021-08-06 中兴通讯股份有限公司 一种业务分流实现方法及装置
CN108696950B (zh) * 2017-03-17 2019-12-20 电信科学技术研究院 一种会话重建的方法、装置、amf、smf及终端
FI3603238T3 (fi) * 2017-03-20 2023-09-12 Zte Corp Verkon viipalointi -palvelutoiminto
US10575220B2 (en) 2017-03-21 2020-02-25 Electronics And Telecommunications Research Institute Session management method based on reallocation of PDU session anchor device, and device performing the session management method
EP3589062B1 (en) * 2017-03-21 2021-05-12 Huawei Technologies Co., Ltd. Communication method and apparatus
CN108738104B (zh) * 2017-04-19 2021-11-19 华为技术有限公司 一种建立本地网络连接的方法、装置、系统和存储介质
WO2018199649A1 (en) * 2017-04-27 2018-11-01 Samsung Electronics Co., Ltd. Method and apparatus for registration type addition for service negotiation
EP3614700B1 (en) * 2017-05-09 2022-11-02 Huawei Technologies Co., Ltd. Data processing method, terminal device and network device
FR3067197A1 (fr) * 2017-06-01 2018-12-07 Orange Procede de selection d'une tranche de reseau relative a une application
CN110771251B (zh) * 2017-06-16 2023-09-22 艾普拉控股有限公司 作为通信网络中的服务的小数据传送、数据缓冲及数据管理
CN110771206B (zh) * 2017-06-19 2021-07-09 Idac控股公司 用户平面重定位方法和装置
CN110663284B (zh) * 2017-06-21 2023-08-04 Lg电子株式会社 在无线通信系统中执行服务请求过程的方法和设备
US11140598B2 (en) * 2017-06-29 2021-10-05 Telefonaktiebolaget Lm Ericsson (Publ) Network initiated inter-RAT handover
US10764789B2 (en) * 2017-08-11 2020-09-01 Comcast Cable Communications, Llc Application-initiated network slices in a wireless network
WO2019035614A1 (en) 2017-08-14 2019-02-21 Samsung Electronics Co., Ltd. ANCHOR USER PLAN (UPF) FUNCTION PROCESSING METHOD FOR LOCAL DELIVERY IN A 5G CELLULAR NETWORK
CN113115272A (zh) * 2017-09-21 2021-07-13 华为技术有限公司 业务重定向方法及装置
EP3846508B1 (en) * 2017-10-09 2025-10-01 Comcast Cable Communications, LLC Policy control for ethernet packet data
US10397791B2 (en) * 2017-10-10 2019-08-27 Futurewei Technologies, Inc. Method for auto-discovery in networks implementing network slicing
US11750708B2 (en) * 2017-10-13 2023-09-05 Telefonaktiebolaget Lm Ericsson (Publ) Method and device for proxy between different architectures
US11576031B2 (en) 2017-10-17 2023-02-07 Telefonaktiebolaget Lm Ericsson (Publ) Service registration in a communications network
CN109673024B (zh) * 2017-10-17 2023-06-30 华为技术有限公司 数据传输通道的处理方法、装置和系统
CN113473391B (zh) * 2017-10-30 2022-10-25 华为技术有限公司 会话建立方法、设备及系统
KR102106778B1 (ko) * 2017-10-31 2020-05-28 에스케이텔레콤 주식회사 데이터 송수신장치 및 데이터 송수신장치의 동작 방법
JP2021504991A (ja) * 2017-11-21 2021-02-15 テレフオンアクチーボラゲット エルエム エリクソン（パブル） アプリケーションのためのトラフィックをハンドリングするための方法および機能
US10805178B2 (en) * 2017-11-27 2020-10-13 Cisco Technology, Inc. Subscription-based event notification techniques for reducing data buffering in mobile networks
US10797894B2 (en) * 2017-12-28 2020-10-06 Ofinno, Llc Service type and device type-based policy and charging control
CN114666859A (zh) * 2018-01-08 2022-06-24 瑞典爱立信有限公司 用于选择服务无线通信设备的会话管理实体的方法和装置
US10623996B2 (en) * 2018-01-15 2020-04-14 Huawei Technologies Co., Ltd GTP tunnels for the support of anchorless backhaul
CN110049070B (zh) * 2018-01-15 2021-09-14 华为技术有限公司 事件通知方法及相关设备
US11057442B2 (en) * 2018-01-27 2021-07-06 Vmware, Inc. System and method for workspace sharing
CN110120988B (zh) * 2018-02-07 2021-03-30 华为技术有限公司 地址管理方法、设备及系统
WO2019158220A1 (en) * 2018-02-19 2019-08-22 Huawei Technologies Duesseldorf Gmbh Apparatus for network slicing and slice management to support multi-slice services
US11463935B2 (en) * 2018-02-20 2022-10-04 Telefonaktiebolaget Lm Ericsson (Publ) Methods and functions for handling local breakout
CN111758244B (zh) * 2018-03-08 2022-03-11 华为技术有限公司 网络功能装置、用于提供端到端通信服务的通信网络
AU2018413527A1 (en) * 2018-03-12 2020-10-15 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Method and apparatus for updating ue policy, and computer storage medium
US11140047B2 (en) * 2018-04-09 2021-10-05 Intel Corporation Network data analytics function (NWDAF) influencing fifth generation (5G) quality of service (QoS) configuration and adjustment
US10511669B2 (en) * 2018-04-26 2019-12-17 Verizon Patent And Licensing Inc. Programmable user plane function
US10798182B2 (en) * 2018-05-17 2020-10-06 Cisco Technology, Inc. Application function control of IP address allocation
PL3797542T3 (pl) * 2018-05-22 2026-01-19 Nokia Solutions And Networks Oy Sposób, urządzenie i nośnik do odczytu komputerowego do egzekwowania reguły związanej z routingiem ruchu
US10484911B1 (en) * 2018-05-23 2019-11-19 Verizon Patent And Licensing Inc. Adaptable radio access network
US11659481B2 (en) * 2018-05-26 2023-05-23 Telefonaktiebolaget Lm Ericsson (Publ) Methods and systems for UE to request appropriate NSSAI in 5G
CN110582126B (zh) 2018-06-11 2021-08-13 华为技术有限公司 一种通信方法及装置
US10924518B2 (en) 2018-06-29 2021-02-16 Cisco Technology, Inc. UPF programming over enhanced N9 interface
CN110661638B (zh) * 2018-06-30 2021-04-20 华为技术有限公司 一种通信方法及装置
CN112385201B (zh) * 2018-07-09 2024-12-24 交互数字专利控股公司 核心网络辅助的服务发现
WO2020013567A1 (ko) 2018-07-10 2020-01-16 삼성전자 주식회사 컨텐츠의 처리 방법 및 장치
WO2020013468A1 (ko) * 2018-07-10 2020-01-16 엘지전자 주식회사 Ladn 영역에 대한 정보가 변경된 경우 단말이 pdu 세션 설립 요청을 수행하는 방법
CN116232667A (zh) * 2018-07-13 2023-06-06 三星电子株式会社 用于边缘计算服务的方法及其电子装置
CN110730487B (zh) * 2018-07-17 2020-12-08 华为技术有限公司 一种选择会话管理功能网元的方法、装置及系统
CN110740149B (zh) * 2018-07-19 2021-04-09 华为技术有限公司 通信方法和装置
US10805841B2 (en) 2018-07-23 2020-10-13 Cisco Technology, Inc. Policy enforcement methods and apparatus for background data transfers involving multiple UEs
EP3827567A1 (en) * 2018-07-24 2021-06-02 Telefonaktiebolaget Lm Ericsson (Publ) Methods, nodes and operator network for enabling filtering of traffic from an application
CN110769420B (zh) * 2018-07-25 2022-05-13 中兴通讯股份有限公司 网络接入方法、装置、终端、基站和可读存储介质
US11611475B2 (en) * 2018-08-02 2023-03-21 Apple Inc. Association of 3GPP (Third Generation Partnership Project) UPF (User Plane Function) and edge computing application server
CN110798833B (zh) * 2018-08-03 2023-10-24 华为技术有限公司 一种鉴权过程中验证用户设备标识的方法及装置
CN109167847B (zh) * 2018-08-09 2021-04-06 中国联合网络通信集团有限公司 一种IPv6地址的生成方法及SMF、通信系统
US11039369B2 (en) * 2018-08-10 2021-06-15 Mediatek Inc. Handling 5G QoS rules on QoS operation errors
EP3834443A1 (en) 2018-08-10 2021-06-16 Nokia Technologies Oy Communication system
CN112567778B (zh) * 2018-08-10 2024-04-05 苹果公司 用于在蜂窝网络中使用无人航空系统的系统和方法
KR102794421B1 (ko) * 2018-08-10 2025-04-15 삼성전자주식회사 무선 통신 시스템에서 네트워크 트래픽 관리 방법 및 장치
CN113347673B (zh) * 2018-08-13 2022-06-24 大唐移动通信设备有限公司 Pdu会话管理、节点关联和upf发现的方法及设备
BR112021001605A2 (pt) * 2018-08-13 2021-04-27 Telefonaktiebolaget Lm Ericsson (Publ) métodos em uma função de exposição de rede e em uma função de controle de política, aparelhos de função de exposição de rede e de função de controle de política, e, mídia legível por computador não transitória
CN110831094B (zh) * 2018-08-14 2021-12-28 华为技术有限公司 一种数据传输通道的处理方法及装置
CN110838926A (zh) * 2018-08-15 2020-02-25 中国移动通信有限公司研究院 管理网络切片的方法及系统
WO2020035357A1 (en) * 2018-08-16 2020-02-20 NEC Laboratories Europe GmbH System and method of multiple application functions influence in 5g networks
US11445335B2 (en) 2018-08-17 2022-09-13 Huawei Technologies Co., Ltd. Systems and methods for enabling private communication within a user equipment group
CN112586060B (zh) * 2018-08-20 2024-07-09 瑞典爱立信有限公司 用于服务发现的方法和装置
WO2020038590A1 (en) * 2018-08-20 2020-02-27 Telefonaktiebolaget Lm Ericsson (Publ) First node, second node, third node, and methods performed thereby for managing data in a database in a communications network
WO2020038563A1 (en) * 2018-08-21 2020-02-27 Telefonaktiebolaget Lm Ericsson (Publ) Technique for preparing user equipment mobility
EP3841790B1 (en) * 2018-08-24 2023-08-09 Nokia Technologies Oy Configuring route selection policies
WO2020039054A1 (en) * 2018-08-24 2020-02-27 Koninklijke Kpn N.V. Information-centric networking over 5g or later networks
US11503498B2 (en) 2018-08-24 2022-11-15 Koninkluke Kpn N.V. Information-centric networking over 5G or later networks
US11388577B2 (en) * 2018-08-28 2022-07-12 Arris Enterprises Llc Station steering profiles in a wireless network control system
CN110891270B (zh) * 2018-09-10 2021-08-27 大唐移动通信设备有限公司 一种鉴权算法的选择方法和装置
KR20200031900A (ko) * 2018-09-17 2020-03-25 삼성전자주식회사 Pdu 세션 제어 방법 및 장치
CN110933711B (zh) * 2018-09-19 2023-06-02 华为技术有限公司 策略控制方法、设备及系统
US11595968B2 (en) 2018-09-26 2023-02-28 Intel Corporation Edge computing deployment scenarios
KR102755137B1 (ko) * 2018-09-27 2025-01-17 삼성전자 주식회사 외부 장치와 통신이 필요한 어플리케이션의 운영 방법 및 전자 장치
WO2020067966A1 (en) * 2018-09-27 2020-04-02 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for interworking between wireless and wired communication networks
CN110972226B (zh) 2018-09-28 2022-04-05 华为技术有限公司 本地局域网通信方法、设备及系统
CN110971421B (zh) * 2018-09-30 2021-06-01 华为技术有限公司 订阅更新方法、设备及系统
KR20200038808A (ko) * 2018-10-04 2020-04-14 삼성전자주식회사 무선 통신 시스템에서 그룹 통신을 제공하는 방법 및 장치
KR102636935B1 (ko) * 2018-10-04 2024-02-14 텔레폰악티에볼라겟엘엠에릭슨(펍) 네트워크 기능(서비스) 프로파일 변경에 대한 구독을 위한 통지
CN112823564B (zh) * 2018-10-04 2024-05-14 瑞典爱立信有限公司 提供动态nef隧道分配的方法和相关的网络节点
US11172426B2 (en) * 2018-10-05 2021-11-09 Qualcomm Incorporated Techniques for routing ID update
KR102814699B1 (ko) * 2018-10-05 2025-05-29 삼성전자주식회사 무선 통신 시스템에서 모바일 엣지 컴퓨팅의 이전을 지원하는 방법 및 장치
KR102456859B1 (ko) 2018-10-05 2022-10-20 삼성전자 주식회사 5g 시스템에서 제공하는 서비스 파라미터를 단말과 네트워크에 프로비져닝하는 방법
CN111010702B (zh) * 2018-10-08 2021-06-29 华为技术有限公司 时延敏感网络通信方法及其装置
EP4192045A1 (en) * 2018-10-09 2023-06-07 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Apparatus and method of performing a group communication
WO2020073960A1 (zh) * 2018-10-10 2020-04-16 中兴通讯股份有限公司 消息通知方法、装置、网元、系统及存储介质
CN111083718B (zh) * 2018-10-22 2023-07-21 中国移动通信有限公司研究院 一种会话管理方法、网络功能及网络系统
CN113179540B (zh) * 2018-10-22 2023-11-03 华为技术有限公司 一种移动切换方法及相关设备
JP7190031B2 (ja) * 2018-10-25 2022-12-14 テレフオンアクチーボラゲット エルエム エリクソン（パブル） 通信システムにおいてアプリケーションごとにポリシルールを実行するための方法およびデバイス
US10848576B2 (en) 2018-10-29 2020-11-24 Cisco Technology, Inc. Network function (NF) repository function (NRF) having an interface with a segment routing path computation entity (SR-PCE) for improved discovery and selection of NF instances
US11575564B2 (en) * 2018-10-31 2023-02-07 Intel Corporation Deploying edge computing
WO2020092174A1 (en) * 2018-11-02 2020-05-07 Intel Corporation Systems, methods, and devices for enabling live media production services
US20200153679A1 (en) * 2018-11-08 2020-05-14 Huawei Technologies Co., Ltd. Method for enhancing status communications in a sdn-based communication system
CN111246453B (zh) * 2018-11-28 2021-06-15 华为技术有限公司 一种数据传输方法、用户面网元及控制面网元
US10798635B2 (en) * 2018-12-03 2020-10-06 At&T Intellectual Property I, L.P. Mobile edge computing for data network traffic
EP3672352A1 (en) * 2018-12-18 2020-06-24 Thales Dis France SA Method for establishing a bidirectional nas signal channel between a secure element cooperating with a terminal and a remote platform
EP3900262B1 (en) * 2018-12-20 2025-06-18 Telefonaktiebolaget Lm Ericsson (Publ) Functions and methods for handling pre-configured profiles for sets of detection and enforcement rules
CN114375069B (zh) * 2018-12-26 2024-04-12 腾讯科技（深圳）有限公司 一种通信方法和网络设备
CN113613264B (zh) * 2018-12-27 2023-03-10 华为技术有限公司 一种通信方法及装置
CN111405635B (zh) * 2019-01-02 2022-07-01 中国移动通信有限公司研究院 能力开放的实现方法、装置、设备及计算机可读存储介质
US20220095111A1 (en) * 2019-01-04 2022-03-24 Telefonaktiebolaget Lm Ericsson (Publ) Flexible authorization in 5g service based core network
CN111436087B (zh) * 2019-01-15 2021-09-10 大唐移动通信设备有限公司 一种pdu会话切换方法及其装置
CN115766337A (zh) * 2019-01-15 2023-03-07 瑞典爱立信有限公司 用于支持局域网（lan）的方法和装置
WO2020147019A1 (en) * 2019-01-15 2020-07-23 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Apparatus and method of performing a group communication
US11343653B2 (en) 2019-01-15 2022-05-24 Ofinno, Llc Session establishment to join a group communication
CN111565429B (zh) * 2019-02-14 2024-12-10 中兴通讯股份有限公司 指示信息的接收方法及装置、存储介质
CN113455029B (zh) 2019-02-15 2024-07-30 三星电子株式会社 无线通信网络中处理ul nas传输消息失败的方法和ue
WO2020169175A1 (en) 2019-02-18 2020-08-27 Huawei Technologies Co., Ltd. Entities for providing an external service to a network
EP4300920B1 (en) 2019-02-18 2025-01-01 Huawei Technologies Co., Ltd. Entities for providing an external service to a network
CN111586602B (zh) * 2019-02-19 2021-07-09 华为技术有限公司 一种策略管理的方法及装置
US11258757B2 (en) * 2019-02-28 2022-02-22 Vmware, Inc. Management of blacklists and duplicate addresses in software defined networks
US11019157B2 (en) 2019-03-06 2021-05-25 At&T Intellectual Property I, L.P. Connectionless service and other services for devices using microservices in 5G or other next generation communication systems
KR102808934B1 (ko) * 2019-03-28 2025-05-21 삼성전자 주식회사 Edge Computing 서비스를 이용하기 위하여 단말에 연결성을 제공하는 방법 및 장치
CN110536282B (zh) * 2019-03-28 2023-03-21 中兴通讯股份有限公司 一种事件通知方法及装置
US12349029B2 (en) 2019-03-28 2025-07-01 Samsung Electronics Co., Ltd. Method and device for providing connectivity to terminal in order to use edge computing service
WO2020204505A1 (ko) 2019-03-29 2020-10-08 삼성전자 주식회사 엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치
CN111757312A (zh) * 2019-03-29 2020-10-09 华为技术有限公司 一种会话的处理方法及装置
US12476953B2 (en) 2019-03-29 2025-11-18 Samsung Electronics Co., Ltd. Method for edge computing service and electronic device therefor
EP3720152B1 (en) * 2019-04-01 2021-10-27 Ntt Docomo, Inc. Communication network components and methods for initiating a slice-specific authentication and authorization
WO2020200287A1 (en) * 2019-04-02 2020-10-08 Huawei Technologies Co., Ltd. Method, apparatus and systems for supporting packet delivery
WO2020207607A1 (en) * 2019-04-11 2020-10-15 Telefonaktiebolaget Lm Ericsson (Publ) Optimization of services applied to data packet sessions
EP3935819A4 (en) * 2019-04-12 2022-06-01 Samsung Electronics Co., Ltd. METHOD AND SYSTEM FOR DISCOVERING AN EDGE SERVER OR SERVICE BY DOMAIN NAME SERVER (DNS) RESOLUTION
US11218438B2 (en) * 2019-04-12 2022-01-04 Huawei Technologies Co., Ltd. System, apparatus and method to support data server selection
EP3942852B1 (en) * 2019-04-29 2024-05-01 Apple Inc. Method and apparatus for enabling service continuity in an edge computing environment
US12160302B2 (en) * 2019-04-30 2024-12-03 Nokia Technologies Oy Receiver beam selection during uplink positioning
WO2020223219A1 (en) * 2019-04-30 2020-11-05 Convida Wireless, Llc Electronic device and methods for performing data aggregation in a 5g user equipment
WO2020222578A1 (ko) * 2019-05-02 2020-11-05 삼성전자 주식회사 Nas 프로토콜을 이용한 세션 및 이동성 관리 방안
WO2020225600A1 (en) * 2019-05-03 2020-11-12 Lenovo (Singapore) Pte, Ltd. Method and apparatus for determining validity
KR102686161B1 (ko) * 2019-05-03 2024-07-18 삼성전자 주식회사 이동통신 시스템에서 시간 또는 서비스 지역에 따른 단말의 세션 설정 관리 방법 및 장치
EP3735006B1 (en) * 2019-05-03 2023-04-05 Nokia Solutions and Networks Oy Efficient computing of application data in mobile communication network
WO2020228966A1 (en) * 2019-05-14 2020-11-19 Telefonaktiebolaget Lm Ericsson (Publ) Technique for grouping terminal devices based on network data analytics information
WO2020236042A1 (en) * 2019-05-17 2020-11-26 Telefonaktiebolaget L M Ericsson (Publ) Network node and method performed therein for providing an application in a communication network
CN113841370B (zh) * 2019-05-17 2024-11-26 瑞典爱立信有限公司 网络节点和在其中实施的用于处理无线通信网络中的通信的方法
WO2020239195A1 (en) * 2019-05-27 2020-12-03 Huawei Technologies Co., Ltd. Network nodes for joint mec host and upf selection
US11026166B2 (en) * 2019-06-07 2021-06-01 Verizon Patent And Licensing Inc. Application driven dynamic network slice selection
CN112087780B (zh) * 2019-06-14 2022-08-30 中国电信股份有限公司 Ims服务提供方法、系统和网络侧服务提供系统
KR102762845B1 (ko) 2019-06-17 2025-02-06 텔레호낙티에볼라게트 엘엠 에릭슨(피유비엘) 애플리케이션 기능과 코어 네트워크 사이에서 협상된 백그라운드 데이터 전송 정책을 업데이트하는 방법, 정책 제어 기능 및 애플리케이션 기능
CN112104757A (zh) * 2019-06-18 2020-12-18 中国移动通信有限公司研究院 Ip地址的配置方法、设备及系统
EP3987739B1 (en) * 2019-06-21 2025-11-19 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatus for device authentication and authorisation
CN112188469B (zh) * 2019-07-01 2022-08-02 中国电信股份有限公司 策略控制方法、装置及计算机可读存储介质
CN110351717B (zh) * 2019-07-18 2021-12-07 中国联合网络通信集团有限公司 终端被动加入异网群组的方法及其装置
CN112291777B (zh) * 2019-07-23 2024-12-06 华为技术有限公司 一种会话管理网元的选择方法、装置及系统
CN112311691B (zh) * 2019-07-26 2024-04-16 华为技术有限公司 策略控制方法、设备及系统
CN112312539B (zh) 2019-07-30 2022-01-14 华为技术有限公司 策略控制功能网元的选择方法、装置、系统及存储介质
JP2021022889A (ja) * 2019-07-30 2021-02-18 ソニー株式会社 ネットワークスライス制御サーバ、サービスサーバ、および、それらの制御方法
US11856489B2 (en) * 2019-08-08 2023-12-26 Qualcomm Incorporated Uplink broadcast/multicast packet processing
US11297534B2 (en) 2019-08-09 2022-04-05 Cisco Technology, Inc. Intelligent and optimal resource selection within a network slice
WO2021029512A1 (ko) * 2019-08-09 2021-02-18 엘지전자 주식회사 어플리케이션 서버의 변경에 관련된 통신
US10841974B1 (en) * 2019-08-12 2020-11-17 Verizon Patent And Licensing Inc. System and method for session relocation at edge networks
EP4440243A3 (en) 2019-08-19 2024-12-18 LG Electronics Inc. Method for relaying unstructured traffic, and relay ue
WO2021032309A1 (en) * 2019-08-20 2021-02-25 Telefonaktiebolaget Lm Ericsson (Publ) Service provision in scenarios with network address translation
CN115426677A (zh) * 2019-08-21 2022-12-02 华为技术有限公司 一种用户面信息上报方法及装置
CN114303438B (zh) * 2019-08-22 2024-01-09 Lg电子株式会社 根据5g中的应用服务器的重定位的高效处理方法
CN114586468B (zh) * 2019-08-22 2025-02-11 Lg电子株式会社 中继ue的针对远端ue的操作方法
CN110505070B (zh) * 2019-08-26 2021-07-27 中国联合网络通信集团有限公司 一种三方会话的建立方法及装置
US10932108B1 (en) 2019-08-28 2021-02-23 Sprint Communications Company L.P. Wireless communication network exposure function (NEF) that indicates network status
WO2021037386A1 (en) * 2019-08-30 2021-03-04 Nokia Technologies Oy Enhancements of registration of nef at nrf
US10785652B1 (en) * 2019-09-11 2020-09-22 Cisco Technology, Inc. Secure remote access to a 5G private network through a private network slice
CN116886588A (zh) * 2019-09-16 2023-10-13 华为技术有限公司 一种通信方法、装置及系统
KR102709500B1 (ko) 2019-09-17 2024-09-25 삼성전자주식회사 무선 통신 시스템에서 psa-upf 재배치를 위한 장치 및 방법
US11363654B2 (en) * 2019-09-17 2022-06-14 At&T Intellectual Property I, L.P. Session mapping in 5G and subsequent generation networks
EP4032253A4 (en) * 2019-09-18 2023-08-30 Telefonaktiebolaget LM Ericsson (publ.) METHOD AND APPARATUS FOR DISCOVERING LOCAL APPLICATION SERVER IN MOBILE EDGE COMPUTING
WO2021062256A1 (en) * 2019-09-25 2021-04-01 Idac Holdings, Inc. Transparent relocation of mec application instances between 5g devices and mec hosts
WO2021058489A1 (en) * 2019-09-26 2021-04-01 Telefonaktiebolaget Lm Ericsson (Publ) Methods, apparatuses and computer-readable media relating to event subscription in a communication network
EP4038939A4 (en) * 2019-09-30 2023-10-04 Telefonaktiebolaget LM Ericsson (publ) Terminal device, application server, network exposure function node and methods therein
CN112583713B (zh) * 2019-09-30 2023-09-29 中兴通讯股份有限公司 流量路由控制方法、网络设备、系统及存储介质
WO2021065804A1 (en) * 2019-09-30 2021-04-08 Nec Corporation Charging in device-to-device communications over pc5 for interactive services
CN112584437B (zh) * 2019-09-30 2023-03-28 中国移动通信有限公司研究院 一种数据分流方法及装置
CN112583880B (zh) * 2019-09-30 2022-02-25 大唐移动通信设备有限公司 一种服务器发现方法及相关设备
KR102797669B1 (ko) * 2019-09-30 2025-04-21 삼성전자 주식회사 무선 통신 시스템에서 무인 항공 시스템 정보를 송수신하는 방법 및 장치
CN112584461B (zh) * 2019-09-30 2023-03-31 华为技术有限公司 路由器通告消息发送方法及装置
EP4038834A1 (en) * 2019-10-02 2022-08-10 Telefonaktiebolaget Lm Ericsson (Publ) Registering and configuring a network function for selectively routing uplink data traffic
US11343698B2 (en) 2019-10-02 2022-05-24 Samsung Electronics Co., Ltd. Method and device for data rate control in network slice in wireless communication system
TWI804686B (zh) 2019-10-03 2023-06-11 財團法人工業技術研究院 網路服務裝置、連線管理裝置及其操作方法
US12114249B2 (en) * 2019-10-04 2024-10-08 Telefonaktiebolaget Lm Ericsson (Publ) Method for identification of traffic suitable for edge breakout and for traffic steering in a mobile network
KR102209719B1 (ko) * 2019-10-07 2021-02-01 에스케이텔레콤 주식회사 통신 시스템에서 사용자 평면을 제어하기 위한 장치 및 이를 위한 방법
CN112637785B (zh) * 2019-10-08 2022-04-29 华为技术有限公司 用于多播传输的方法和装置
CN112654100B9 (zh) * 2019-10-10 2023-11-03 中国移动通信有限公司研究院 一种信息处理方法和相关网络设备
KR102796677B1 (ko) * 2019-10-10 2025-04-16 삼성전자주식회사 엣지 컴퓨팅 서비스를 위한 방법 및 장치
KR102739589B1 (ko) * 2019-10-14 2024-12-06 삼성전자주식회사 무선 통신 시스템에서 데이터 패킷을 송수신하는 방법 및 장치
US11134416B2 (en) * 2019-10-16 2021-09-28 Verizon Patent And Licensing Inc. Control plane traffic load balancing, protection, and network selection
KR102240352B1 (ko) * 2019-10-22 2021-04-14 주식회사 엘지유플러스 5g 기반 lan 서비스 제공 장치
CN112752254B (zh) * 2019-10-31 2022-05-06 大唐移动通信设备有限公司 一种信息处理方法、装置、设备及计算机可读存储介质
CN112788593B (zh) * 2019-11-04 2024-07-05 阿里巴巴集团控股有限公司 安全策略的更新方法及装置、系统
CN114902634B (zh) * 2019-11-05 2024-10-29 三星电子株式会社 移动通信系统中提供应用服务器的信息的设备和方法
US20210136674A1 (en) * 2019-11-06 2021-05-06 Samsung Electronics Co., Ltd. Method and apparatus for managing network slices in wireless communication system
CN115039439A (zh) 2019-11-06 2022-09-09 瑞典爱立信有限公司 用于配置用于用户设备的数据会话的方法
WO2021087947A1 (en) 2019-11-08 2021-05-14 Zte Corporation A method for influencing data traffic routing in a core network
EP4044666A4 (en) * 2019-11-08 2022-10-19 Huawei Technologies Co., Ltd. Traffic flow routing method, device, and system
EP3826340A1 (en) * 2019-11-21 2021-05-26 Thales Dis France Sa Method for authenticating a user on a network slice
CN112953998A (zh) * 2019-12-11 2021-06-11 英特尔公司 用于ue不知情的eas ip地址替换的装置和方法
CN112106386B (zh) * 2019-12-16 2023-07-28 钟杰东 一种5g应用终端业务管理系统及其管理方法
CN112995117B (zh) * 2019-12-18 2022-09-16 中国电信股份有限公司 业务请求的处理方法、装置、系统和计算机可读存储介质
CN118890624A (zh) * 2019-12-26 2024-11-01 日本电气株式会社 第一通信设备、用户设备及其方法
CN113133129B (zh) * 2019-12-30 2025-03-21 华为技术有限公司 一种业务处理的方法、装置和系统
CN113133131B (zh) * 2019-12-31 2022-12-13 华为技术有限公司 一种通信方法及装置
CN113067907B (zh) * 2020-01-02 2023-04-07 中国移动通信有限公司研究院 一种边缘应用寻址的方法和相关设备
CN113079584B (zh) * 2020-01-06 2022-07-15 大唐移动通信设备有限公司 Ec平台的会话管理方法、smf网元及amf网元
EP4088512A4 (en) * 2020-01-07 2023-09-27 Lenovo (Beijing) Limited METHOD AND APPARATUS FOR SELECTING A USER LEVEL FUNCTION
CN114930901B (zh) * 2020-01-15 2024-08-16 中兴通讯股份有限公司 利用多接入相关的信息配置流量导向
US11770734B2 (en) * 2020-01-28 2023-09-26 Verizon Patent And Licensing Inc. Method and system for edge network exposure function with MEC network
CN113259930A (zh) * 2020-02-10 2021-08-13 大唐移动通信设备有限公司 调用的请求、查询、授权处理方法、设备及装置、介质
US12185197B2 (en) 2020-02-10 2024-12-31 Telefonaktiebolaget L M Ericsson (Publ) Methods and apparatuses for SMS delivery
CN115023968B (zh) * 2020-02-12 2025-09-05 华为技术有限公司 一种业务处理方法、装置以及系统
EP4104386A4 (en) * 2020-02-14 2023-10-25 Lenovo (Beijing) Limited IMPROVED SERVER DISCOVERY WHEN CHANGING APPLICATION SERVERS
US12513561B2 (en) 2020-02-14 2025-12-30 Telefonaktiebolaget Lm Ericsson (Publ) Method and network node for QoS notification
US11323550B2 (en) 2020-02-17 2022-05-03 Cisco Technology, Inc. Techniques to send load-share notifications to multiple receivers
WO2021166644A1 (ja) * 2020-02-18 2021-08-26 ソニーグループ株式会社 通信装置及び通信方法
WO2021168714A1 (zh) * 2020-02-26 2021-09-02 华为技术有限公司 一种发现应用的方法、装置及系统
EP4521718A3 (en) 2020-02-27 2025-06-18 Ofinno, LLC Session management for edge computing
WO2021179272A1 (en) * 2020-03-12 2021-09-16 Nokia Shanghai Bell Co., Ltd. Dynamical change in access and mobility policy
CN111343092B (zh) * 2020-03-15 2021-10-22 腾讯科技（深圳）有限公司 基于边缘计算的通信方法、装置、介质及电子设备
KR20210118608A (ko) 2020-03-23 2021-10-01 삼성전자주식회사 UPF 서비스 기반 Packet Delay Status Event Exposure Service 방법 및 장치
CN113453292B (zh) * 2020-03-25 2023-09-01 华为技术有限公司 一种建立连接的方法和通信装置以及系统
JP2021158499A (ja) * 2020-03-26 2021-10-07 ソニーグループ株式会社 アプリケーションファンクションノード及び通信方法
CN113473446B (zh) * 2020-03-31 2022-08-30 中国电信股份有限公司 用户面改变方法、系统和移动边缘计算网元
CN113473526A (zh) * 2020-03-31 2021-10-01 华为技术有限公司 一种通信方法及装置
CN113473569B (zh) * 2020-03-31 2023-05-12 华为技术有限公司 应用服务器的发现方法及相关装置
CN113498083B (zh) 2020-04-07 2023-06-02 华为技术有限公司 通信方法、装置及系统
WO2021204406A1 (en) * 2020-04-08 2021-10-14 Telefonaktiebolaget Lm Ericsson (Publ) Service-based user plane entity for a wireless communication network
KR20210125389A (ko) 2020-04-08 2021-10-18 삼성전자주식회사 Target AF로 Notification을 전송하는 방법 및 장치
CN113543270A (zh) * 2020-04-16 2021-10-22 华为技术有限公司 数据传输方法及通信装置
EP4136822B1 (en) * 2020-04-16 2024-08-14 Telefonaktiebolaget LM ERICSSON (PUBL) User plane based exposure
CN113543171A (zh) * 2020-04-22 2021-10-22 联发科技股份有限公司 因特网协议3元组组件的处理方法及其用户设备
CN121001073A (zh) * 2020-04-30 2025-11-21 腾讯科技（深圳）有限公司 用于实现业务连续性的方法及相关设备
WO2021097497A2 (en) * 2020-05-04 2021-05-20 Futurewei Technologies, Inc. Methods and apparatus for session steering to application servers
CN111754769B (zh) * 2020-05-22 2021-06-08 浙江工业大学 基于含长程连边的曼哈顿城市网络的路网交通流特性仿真方法
US20240334300A1 (en) * 2020-06-25 2024-10-03 Nokia Solutions And Networks Oy Application function relocation procedure
EP4173331B1 (en) 2020-06-26 2025-08-27 Telefonaktiebolaget LM Ericsson (publ) Policy provisioning to a mobile communication system
US12490097B2 (en) 2020-06-26 2025-12-02 Nec Corporation Core network node, MEC server, external server, communication system, control method, program, and non-transitory recording medium having recorded thereon program
CN117118841A (zh) * 2020-06-28 2023-11-24 中兴通讯股份有限公司 网络切片连接管理方法、终端及计算机可读存储介质
CN113873582B (zh) * 2020-06-30 2023-03-28 华为技术有限公司 一种移动边缘计算处理方法以及相关设备
US11196680B1 (en) * 2020-07-27 2021-12-07 Verizon Patent And Licensing Inc. Systems and methods for configuring an application platform using resources of a network
KR102423876B1 (ko) * 2020-07-29 2022-07-21 네이버 주식회사 어플리케이션 리소스 최적화를 위한 방법과 시스템
EP4176608A4 (en) 2020-08-06 2024-03-27 Apple Inc. NETWORK AUTHENTICATION FOR A USER DEVICE'S ACCESS TO AN EDGE DATA NETWORK
WO2022031201A1 (en) * 2020-08-06 2022-02-10 Telefonaktiebolaget Lm Ericsson (Publ) Methods, apparatus and machine-readable media relating to migration in a wireless communication network
WO2022027505A1 (en) * 2020-08-06 2022-02-10 Apple Inc. User equipment authentication and authorization procedure for edge data network
US12349006B2 (en) 2020-08-11 2025-07-01 Telefonaktiebolaget Lm Ericsson (Publ) Coordination of edge application server reselection using edge client subnet
WO2022034525A1 (en) * 2020-08-11 2022-02-17 Telefonaktiebolaget Lm Ericsson (Publ) Re-anchoring with smf re-selection
CN114143701B9 (zh) * 2020-08-12 2023-05-19 维沃移动通信有限公司 设备的查找和注册方法、网络侧设备
US11659440B2 (en) 2020-08-12 2023-05-23 Cisco Technology, Inc. Binding indications for load balancing and redundancy for communications between network function instances in a 5G core network
CN116916402A (zh) * 2020-08-12 2023-10-20 瑞典爱立信有限公司 用于在重定位时协调到边缘应用服务器的无缝服务连续性的机制
EP4197228A1 (en) * 2020-08-12 2023-06-21 InterDigital Patent Holdings, Inc. Edge application server relocation
WO2022032547A1 (zh) * 2020-08-12 2022-02-17 华为技术有限公司 一种应用迁移的方法和装置
US20220053444A1 (en) * 2020-08-13 2022-02-17 Alibaba Group Holding Limited Network Communication Method and Apparatus
US11350303B2 (en) * 2020-08-25 2022-05-31 Verizon Patent And Licensing Inc. Mobile network conditional policy execution based on UE geographic location
CN114268591B (zh) * 2020-09-16 2024-03-26 华为技术有限公司 数据分流方法和装置
CN112118600B (zh) * 2020-09-18 2024-05-03 恒安嘉新（北京）科技股份公司 一种5g独立组网sa架构下的流量牵引系统
US11246011B1 (en) 2020-09-29 2022-02-08 Cisco Technology, Inc. Cellular access of user-defined networks
CN115885570B (zh) 2020-09-30 2025-08-08 华为技术有限公司 一种通信方法、装置及计算机可读存储介质
CN114363393B (zh) * 2020-09-30 2025-10-03 中兴通讯股份有限公司 Pfd管理方法、网元及计算机可读存储介质
KR20220057719A (ko) * 2020-10-30 2022-05-09 삼성전자주식회사 캐리어 네트워크를 이용하는 전자 장치 및 그 동작 방법
WO2022115010A1 (en) * 2020-11-24 2022-06-02 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for exposing radio access network (ran) data
CN114640994B (zh) * 2020-12-16 2024-11-15 中国电信股份有限公司 协议数据单元会话鉴权认证方法、系统和相关设备
US20240056321A1 (en) * 2020-12-18 2024-02-15 Telefonaktiebolaget Lm Ericsson (Publ) Dynamic membership for an application group in a mobile communication system
US11444914B2 (en) 2020-12-23 2022-09-13 Cisco Technology, Inc. Quality of service (QoS) policy selection and flow creation based on domain name system (DNS) application metadata
US11463856B1 (en) 2021-01-07 2022-10-04 Sprint Communications Company L.P. Uplink data burst in a wireless communication network
US11601877B2 (en) * 2021-01-08 2023-03-07 Verizon Patent And Licensing Inc. Systems and methods for exposing network slices for third party applications
CN114765800A (zh) * 2021-01-14 2022-07-19 维沃移动通信有限公司 传输方法、传输装置、通信设备及可读存储介质
US11445410B2 (en) * 2021-01-21 2022-09-13 Sprint Communications Company L.P. Wireless communication service delivery responsive to user equipment (UE) handovers
US11395111B1 (en) 2021-01-28 2022-07-19 Sprint Communications Company Lp User charging over an exposure function in a wireless communication network
EP4289155A1 (en) * 2021-02-05 2023-12-13 Telefonaktiebolaget LM Ericsson (publ) Service function chaining exposure in 5g networks
US12549635B2 (en) * 2021-02-11 2026-02-10 Verizon Patent And Licensing Inc. Systems and methods for exposing user equipment identities to applications
US11956627B2 (en) * 2021-02-19 2024-04-09 Nokia Technologies Oy Securing user equipment identifier for use external to communication network
CN114980033B (zh) * 2021-02-26 2024-10-22 维沃移动通信有限公司 原生算力业务实现方法、装置、网络设备及终端
EP4302526A1 (en) * 2021-03-03 2024-01-10 Telefonaktiebolaget LM Ericsson (publ) Nf discovery between different networks such as different snpns
KR20220125503A (ko) 2021-03-05 2022-09-14 삼성전자주식회사 네트워크 슬라이스와 데이터 세션을 수립하는 전자 장치 및 그 동작 방법
US11743062B2 (en) * 2021-03-05 2023-08-29 Verizon Patent And Licensing Inc. Method and system for multi-operator anchor service
US11778548B2 (en) 2021-03-09 2023-10-03 Kyndryl, Inc. Deploying containers on a 5G slice network
KR20220128714A (ko) * 2021-03-15 2022-09-22 삼성전자주식회사 Pfd 관리 절차에서 양방향 필터를 프로비저닝하는 방법 및 장치
US11497069B1 (en) 2021-03-16 2022-11-08 Sprint Communications Company Lp Wireless communication network to serve a protocol data unit (PDU) session type over a radio access network (RAN)
US11602003B1 (en) 2021-03-17 2023-03-07 T-Mobile Innovations Llc Wireless communication network to serve a user equipment (UE) over a user plane function group (UPFG)
US11589295B1 (en) 2021-03-18 2023-02-21 T-Mobile Innovations Llc Network function provisioning over third generation partnership project (3GPP) links
KR20230145485A (ko) * 2021-03-20 2023-10-17 텔레폰악티에볼라겟엘엠에릭슨(펍) 단말 디바이스를 서빙하기 위한 구성을 제공하기 위한 방법 및 장치
CN115669014B (zh) * 2021-03-30 2025-08-12 北京小米移动软件有限公司 一种用于用户设备组的策略协调方法及装置
US11540112B1 (en) 2021-04-01 2022-12-27 Sprint Communications Company Lp Policy enforcement across wireless communication networks over application functions
US12507040B2 (en) * 2021-04-06 2025-12-23 Nokia Technologies Oy Distributing multicast packets in individual protocol data unit (PDU) sessions
US11882538B1 (en) * 2021-04-08 2024-01-23 T-Mobile Innovations Llc Wireless user equipment (UE) registration with networking data responsive to external control
US20220353263A1 (en) * 2021-04-28 2022-11-03 Verizon Patent And Licensing Inc. Systems and methods for securing network function subscribe notification process
US12289695B2 (en) * 2021-05-04 2025-04-29 Electronics And Telecommunications Research Institute Method for providing time synchronization service for 5G system external application service
US20240243987A1 (en) * 2021-05-10 2024-07-18 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus of failure handling for traffic steering
WO2022244532A1 (ja) * 2021-05-18 2022-11-24 日本電気株式会社 Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎノード、Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ、及びこれらの方法
US11956702B2 (en) * 2021-05-18 2024-04-09 T-Mobile Innovations Llc User equipment (UE) service over a network exposure function (NEF) in a wireless communication network
CN115379509A (zh) * 2021-05-18 2022-11-22 中国移动通信有限公司研究院 业务处理方法、设备及可读存储介质
US12382415B1 (en) 2021-05-20 2025-08-05 T-Mobile Innovations Llc Network function registration with network repository functions
US11811652B2 (en) 2021-05-27 2023-11-07 Cisco Technology, Inc. Packet flow management for quality of service (QOS) flows in a private 5G network
CN115442792B (zh) * 2021-06-03 2025-09-05 华为技术有限公司 接入业务的方法、装置和系统
US11528660B1 (en) 2021-06-23 2022-12-13 Sprint Communications Company Lp Wireless communication service over a network slice that comprises a network exposure function (NEF)
US11638134B2 (en) * 2021-07-02 2023-04-25 Oracle International Corporation Methods, systems, and computer readable media for resource cleanup in communications networks
US20240314673A1 (en) * 2021-07-05 2024-09-19 Telefonaktiebolaget Lm Ericsson (Publ) Monitoring wireless devices in a communication network
US11582636B1 (en) 2021-07-12 2023-02-14 T-Mobile Innovations Llc Wireless communication service over a wireless network slice based on user equipment (UE) concentrations
CN115835167A (zh) * 2021-08-05 2023-03-21 华为技术有限公司 发现边缘应用服务器的方法及装置
US11809924B2 (en) * 2021-08-10 2023-11-07 T-Mobile Innovations Llc Wireless communication service over a network exposure function (NEF) that has an application programming interface (API)
US11582641B1 (en) 2021-08-12 2023-02-14 Dish Wireless L.L.C. User plane function (UPF) load balancing based on current UPF load and thresholds that depend on UPF capacity
US11483738B1 (en) 2021-08-26 2022-10-25 Dish Wireless L.L.C. User plane function (UPF) load balancing based on network data analytics to predict load of user equipment
US11627492B2 (en) 2021-08-26 2023-04-11 Dish Wireless L.L.C. User plane function (UPF) load balancing based on special considerations for low latency traffic
US11595851B1 (en) 2021-08-27 2023-02-28 Dish Wireless L.L.C. User plane function (UPF) load balancing supporting multiple slices
US12082307B2 (en) 2021-09-01 2024-09-03 Cisco Technology, Inc. Techniques for binding operator-defined network service configurations to applications
CN115755027A (zh) * 2021-09-02 2023-03-07 维沃移动通信有限公司 感知业务的处理方法和设备
CN115884074A (zh) * 2021-09-30 2023-03-31 华为技术有限公司 一种应用服务器的确定方法
US11785423B1 (en) * 2021-10-06 2023-10-10 T-Mobile Innovations Llc Delivery of geographic location for user equipment (UE) in a wireless communication network
US11864099B2 (en) 2021-10-22 2024-01-02 T-Mobile Innovations Llc Unified data repository (UDR) access across wireless communication networks
CN116074744A (zh) * 2021-11-01 2023-05-05 中国移动通信集团江苏有限公司 控制网络服务区域的方法和装置
US12021949B2 (en) * 2021-11-03 2024-06-25 Tencent America LLC Method for application context transfer between edge servers in 5G networks
CN116074202B (zh) * 2021-11-04 2024-08-27 中移物联网有限公司 一种切片信息处理方法、设备及计算机可读存储介质
US11950138B2 (en) 2021-11-17 2024-04-02 Dish Wireless L.L.C. Predictive user plane function (UPF) load balancing based on network data analytics
CN114006884B (zh) * 2021-11-17 2024-03-15 中国电信股份有限公司 网络地址转换场景下的会话控制方法、装置和系统
US12382379B2 (en) 2021-11-29 2025-08-05 T-Mobile Innovations Llc Network exposure function (NEF) slice in a wireless communication network
US11876866B2 (en) 2021-11-29 2024-01-16 Industrial Technology Research Institute Method for assisting unregistered user device to access end-to-end call service of private network and communication system
US12160809B2 (en) 2021-12-14 2024-12-03 Cisco Technology, Inc. Facilitating user equipment to user equipment communications in a mobile network environment
CN114285787B (zh) * 2021-12-30 2023-07-14 中国电信股份有限公司 跨用户面转发方法、系统和计算机可读存储介质
US11985501B2 (en) 2022-01-12 2024-05-14 T-Mobile Innovations Llc Third generation partnership project (3GPP) service delivery to non-3GPP user devices over 3GPP N1 links
US12160743B2 (en) * 2022-01-19 2024-12-03 Oracle International Corporation Methods, systems, and computer readable media for providing call intelligence to a signaling firewall in a communications network
KR20230115696A (ko) * 2022-01-27 2023-08-03 삼성전자주식회사 이동통신 시스템에서 고 신뢰 및 저 지연 통신 서비스를 제공하기 위한 방법 및 장치
CN116567529B (zh) * 2022-01-28 2025-11-21 维沃移动通信有限公司 终端策略更新方法、终端及通信设备
US20230247482A1 (en) * 2022-01-31 2023-08-03 Nokia Technologies Oy Access traffic steering, switching, and splitting with branching point or uplink classifier on the path
CN116669114A (zh) * 2022-02-21 2023-08-29 维沃移动通信有限公司 信息公开的方法及通信设备
CN116683967A (zh) * 2022-02-22 2023-09-01 华为技术有限公司 通信方法和装置
GB202204488D0 (en) 2022-03-29 2022-05-11 Samsung Electronics Co Ltd Artificial intelligence and machine learning traffic transport
US20250219935A1 (en) * 2022-03-29 2025-07-03 Lenovo (Beijing) Limited Method and apparatus of traffic routing control
EP4503836A1 (en) * 2022-03-29 2025-02-05 China Mobile Communication Co., Ltd Research Institute Network information opening method and apparatus, related device and storage medium
US12537742B2 (en) * 2022-05-06 2026-01-27 Qualcomm Incorporated Negotiation and notification of protocol data unit (PDU) set or data burst marking mechanisms
US12169634B2 (en) * 2022-06-29 2024-12-17 Western Digital Technologies, Inc. Asynchronous operation completion notification
EP4550925A1 (en) * 2022-06-30 2025-05-07 Ntt Docomo, Inc. Network node, base station, and communication method
WO2024040436A1 (en) * 2022-08-23 2024-02-29 Zte Corporation Wireless communication schemes for supporting network slicing
KR20240044772A (ko) * 2022-09-29 2024-04-05 삼성전자주식회사 무선 통신 시스템에서 멀티모달리티 서비스를 위한 통신 방법 및 장치
CN117793199A (zh) * 2022-09-29 2024-03-29 华为技术有限公司 通信方法、通信装置、以及通信系统
KR20240063563A (ko) * 2022-11-03 2024-05-10 삼성전자주식회사 무선 통신 시스템에서 트래픽 특성 변화에 기반하여 정보를 전달하는 방법 및 장치
CN118317289A (zh) * 2023-01-06 2024-07-09 华为技术有限公司 通信方法、装置和系统
WO2024166188A1 (ja) * 2023-02-06 2024-08-15 株式会社Ｎｔｔドコモ ネットワークノード及び制御方法
CN118612761A (zh) * 2023-02-28 2024-09-06 华为技术有限公司 一种通信方法及装置
CN116390080A (zh) * 2023-03-10 2023-07-04 博瑞得科技有限公司 一种用于关联信息的信令数据分发方法
US12487847B2 (en) * 2023-04-14 2025-12-02 At&T Intellectual Property I, L.P. Virtual firewall for use in a private mobile core
CN121532763A (zh) * 2023-05-17 2026-02-13 瑞典爱立信有限公司 对许可的改变或许可的有效性的指示
US20240406714A1 (en) * 2023-06-01 2024-12-05 Qualcomm Incorporated User plane programmable layer for radio communications
WO2025017726A1 (en) * 2023-07-19 2025-01-23 Jio Platforms Limited Method and system for creating a network area
WO2025017736A1 (en) * 2023-07-20 2025-01-23 Jio Platforms Limited System and method for transferring complete filter information to session management function
KR20250024408A (ko) * 2023-08-11 2025-02-18 삼성전자주식회사 펨토 기지국을 이용하는 무선 통신 시스템에서 단말의 데이터 트래픽을 전달하기 위한 네트워크를 선택하기 위한 방법 및 장치
WO2025093191A1 (en) * 2023-10-30 2025-05-08 Telefonaktiebolaget Lm Ericsson (Publ) Network management
US20250202806A1 (en) * 2023-12-13 2025-06-19 Cisco Technology, Inc. Intent-based application steering using sd-wan router affinity
WO2025250051A1 (ru) * 2024-05-31 2025-12-04 Александр Юрьевич БАРАНОВ Устройство хранения данных для мобильного устройства и способ маршрутизации трафика

Family Cites Families (62)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7363354B2 (en) * 2001-11-29 2008-04-22 Nokia Corporation System and method for identifying and accessing network services
US7424293B2 (en) 2003-12-02 2008-09-09 Telecommunication Systems, Inc. User plane location based service using message tunneling to support roaming
JP4567745B2 (ja) 2005-09-29 2010-10-20 富士通株式会社 通信システムにおける通信の切り替え方法
RU2384020C2 (ru) 2005-09-30 2010-03-10 Телефонактиеболагет Лм Эрикссон (Пабл) Средства и способы для улучшения характеристик хэндовера интегрированных сетей радиодоступа
CN101472314B (zh) 2007-11-02 2010-05-12 华为技术有限公司 一种数据处理方法和设备
US8503333B2 (en) 2008-08-21 2013-08-06 Telefonaktiebolaget Lm Ericsson Reestablishment of an interface between nodes in a network using a backoff time
US8972553B2 (en) 2009-08-10 2015-03-03 Qualcomm Incorporated Method and apparatus for handling policy and charging control rule or quality of service rule modification failures
CN102006639B (zh) 2009-09-03 2014-01-01 华为技术有限公司 切换处理方法和系统、中继装置以及基站
US9237174B2 (en) 2010-02-10 2016-01-12 Panasonic Intellectual Property Management Co., Ltd. System and method to keep continuity of media flows for a collaborative session without constant controller(s) involvement
CN102158897B (zh) 2010-02-12 2015-04-01 中兴通讯股份有限公司 基于网络负荷进行编码选择的方法和系统
CN102811473B (zh) 2011-05-30 2016-06-22 中兴通讯股份有限公司 无线链路控制参数的处理方法及系统、无线网络控制器
CN102868994A (zh) 2011-07-08 2013-01-09 北京三星通信技术研究有限公司 一种支持用户设备ue移动性的方法
CN102238691B (zh) 2011-07-25 2018-03-16 中兴通讯股份有限公司 一种融合不同接入技术的通信系统及方法
WO2013170897A1 (en) 2012-05-16 2013-11-21 Telefonaktiebolaget L M Ericsson (Publ) Routing of traffic in a multi-domain network
EP2670195A1 (en) * 2012-05-31 2013-12-04 Telefonaktiebolaget L M Ericsson AB (Publ) Methods and apparatus for mitigating service interruption
KR20140018089A (ko) * 2012-07-25 2014-02-12 삼성전자주식회사 무선 통신 시스템에서 혼잡을 고려한 트래픽 오프로딩 방법 및 장치
CN108601051B (zh) 2012-08-10 2021-10-08 荣耀终端有限公司 一种切换控制方法及装置
US20150236985A1 (en) 2012-08-31 2015-08-20 Nokia Solutions And Networks Oy Optimizations for Frequent Small Data Transmission
WO2014060036A1 (en) 2012-10-18 2014-04-24 Nokia Solutions And Networks Oy Intelligent bearer setup configuration control
WO2014110410A1 (en) * 2013-01-11 2014-07-17 Interdigital Patent Holdings, Inc. User-plane congestion management
EP2947924A4 (en) 2013-01-31 2016-03-02 Huawei Tech Co Ltd METHOD, DEVICE, AND ACCESS PROCESSING SYSTEM
US9204256B2 (en) 2013-03-11 2015-12-01 Qualcomm Incorporated Method and apparatus for providing user plane or control plane position services
US10034321B2 (en) 2013-06-20 2018-07-24 Telefonaktiebolaget Lm Ericsson (Publ) Machine type communication virtual shared mobile apparatus and method
EP3021535A4 (en) 2013-07-11 2017-01-25 Nec Corporation Communication system and communication device, and control method and control device therefor
WO2014173252A1 (zh) 2013-07-26 2014-10-30 中兴通讯股份有限公司 会话管理方法、应用功能实体、策略服务器和协议转换器
JPWO2015029417A1 (ja) 2013-08-26 2017-03-02 日本電気株式会社 通信システムにおける通信装置および方法、通信パスの制御装置および方法
US9467480B2 (en) * 2013-09-16 2016-10-11 Qualcomm Incorporated Selectively multiplexing incoming WebRTC traffic and/or de-multiplexing outgoing WebRTC traffic by a client-based WebRTC proxy on behalf of a WebRTC multimedia client application
CN104581670B (zh) 2013-10-15 2019-03-15 中兴通讯股份有限公司 应用接入控制方法及应用功能实体装置
JP5910623B2 (ja) 2013-12-25 2016-04-27 トヨタ自動車株式会社 車両用ポップアップフード装置
CN104767722B (zh) 2014-01-08 2019-02-19 中兴通讯股份有限公司 会话的管理方法、策略服务器及应用功能装置
US9894464B2 (en) 2014-03-14 2018-02-13 Intel IP Corporation Conveyance of application communication patterns from an external application server to a 3rd generation partnership project system
JP2015177385A (ja) 2014-03-17 2015-10-05 株式会社日立製作所 ゲートウェイおよびセッション制御方法
CN106233757B (zh) 2014-03-31 2021-11-02 康维达无线有限责任公司 M2m服务层与3gpp网络之间的过载控制和协调
US10462626B2 (en) 2014-09-23 2019-10-29 Nokia Solutions And Networks Oy Control of communication using service function chaining
KR102406960B1 (ko) 2014-11-07 2022-06-10 삼성전자 주식회사 단말에게 그룹 메시지를 전송하는 방법 및 장치
WO2016072814A1 (en) 2014-11-07 2016-05-12 Samsung Electronics Co., Ltd. Method and apparatus for transmitting group message to user equipment (ue)
US9730156B1 (en) 2014-11-07 2017-08-08 Cisco Technology, Inc. System and method for providing power saving mode enhancements in a network environment
EP3177063B1 (en) 2014-11-10 2019-06-26 Huawei Technologies Co., Ltd. Congestion notification method, related device and system
KR102220181B1 (ko) * 2014-11-28 2021-02-25 삼성전자주식회사 단말간 스폰서링 서비스를 제공하기 위한 방법 및 장치
US10694558B2 (en) 2015-03-01 2020-06-23 Cisco Technology, Inc. System, method and apparatus for small cell gateway selective data path offload
US9893939B2 (en) 2015-03-22 2018-02-13 Lg Electronics Inc. Method for transmitting and receiving signal related to monitoring by SCEF in wireless communication system and apparatus for the same
US9668236B2 (en) 2015-03-25 2017-05-30 Lg Electronics Inc. Method and apparatus for monitoring user equipment reachability in wireless communication system
EP3282732B1 (en) 2015-04-05 2020-06-03 LG Electronics Inc. Method for adjusting tracking area update timing in wireless communication system
WO2016202363A1 (en) 2015-06-16 2016-12-22 Telefonaktiebolaget Lm Ericsson (Publ) Handling a service chain for a ue which roams into a visited network
US10035511B2 (en) 2015-07-27 2018-07-31 Cummins Inc. Method and system for controlling operation of an engine powered device having cyclical duty cycles
CN108141781A (zh) 2015-10-28 2018-06-08 英特尔公司 用于基于sdn的蜂窝网络架构的服务质量配置框架
WO2017095809A1 (en) 2015-11-30 2017-06-08 Intel Corporation Mobile-terminated packet transmission
EP3386220B1 (en) 2016-01-18 2021-08-11 Samsung Electronics Co., Ltd. Methods and apparatus for communication in a mobile communication system
WO2017127102A1 (en) 2016-01-22 2017-07-27 Nokia Solutions And Networks Oy Application relocation between clouds
US10616936B2 (en) 2016-02-17 2020-04-07 Nec Corporation Method for (re)selection of control plane and user plane data transmission
CN107241369B (zh) 2016-03-28 2020-06-16 电信科学技术研究院 一种数据传输的方法、装置及会话管理功能实体设备
US10257078B2 (en) 2016-04-01 2019-04-09 Qualcomm Incorporated Interworking with legacy radio access technologies for connectivity to next generation core network
US10841847B2 (en) 2016-04-29 2020-11-17 Lg Electronics Inc. Data transmission method performed by base station in wireless communication system, and apparatus using same
US11444850B2 (en) 2016-05-02 2022-09-13 Huawei Technologies Co., Ltd. Method and apparatus for communication network quality of service capability exposure
US10362511B2 (en) 2016-05-17 2019-07-23 Lg Electronics Inc. Method and apparatus for determining PDU session identity in wireless communication system
US12261756B2 (en) 2016-06-15 2025-03-25 Qualcomm Incorporated Data packet store, forward, and monitoring functionality for network node or modem
US11184830B2 (en) 2016-06-21 2021-11-23 Huawei Technologies Co., Ltd. Systems and methods for user plane path selection, reselection, and notification of user plane changes
WO2018008980A1 (ko) * 2016-07-05 2018-01-11 엘지전자(주) 무선 통신 시스템에서 사용자가 선호하는 자원 운용 선택 방법 및 이를 위한 장치
CN106210042B (zh) 2016-07-11 2019-06-18 清华大学 一种基于端到端网络切片的用户服务请求选择方法
US10212639B2 (en) 2016-07-26 2019-02-19 At&T Intellectual Property I, L.P. Method and apparatus for dynamic data path selection for narrow band wireless communication
US9781259B1 (en) 2016-07-27 2017-10-03 At&T Intellectual Property I, L.P. Method and apparatus for asset location tracking in a communication network
US10972552B2 (en) 2016-09-30 2021-04-06 Huawei Technologies Co., Ltd. Method and system for user plane path selection

Also Published As

Publication number Publication date
RU2758457C2 (ru) 2021-10-28
US10531420B2 (en) 2020-01-07
JP2023038289A (ja) 2023-03-16
EP3494718B1 (en) 2020-08-26
US20180192471A1 (en) 2018-07-05
BR112019006086A2 (pt) 2019-09-17
JP2019536305A (ja) 2019-12-12
CN118450540A (zh) 2024-08-06
CN110169089B (zh) 2021-03-23
EP3755012B1 (en) 2024-01-03
US10812977B2 (en) 2020-10-20
KR20190044661A (ko) 2019-04-30
EP3494718A1 (en) 2019-06-12
EP4329370A3 (en) 2024-03-06
CN113329374A (zh) 2021-08-31
JP2021093762A (ja) 2021-06-17
US20200128503A1 (en) 2020-04-23
CN110996303A (zh) 2020-04-10
RU2019109163A3 (es) 2021-06-21
JP6848054B2 (ja) 2021-03-24
US20210345108A1 (en) 2021-11-04
WO2018127148A1 (en) 2018-07-12
JP7217303B2 (ja) 2023-02-02
KR102167343B1 (ko) 2020-10-19
US20180192390A1 (en) 2018-07-05
WO2018127147A1 (en) 2018-07-12
US11096046B2 (en) 2021-08-17
JP7511694B2 (ja) 2024-07-05
EP4329370A2 (en) 2024-02-28
CN113329374B (zh) 2025-05-06
US11838756B2 (en) 2023-12-05
RU2019109163A (ru) 2020-09-30
CN110169089A (zh) 2019-08-23
CN110996303B (zh) 2020-11-10
EP3494718A4 (en) 2019-06-26
EP4329370B1 (en) 2025-03-12
EP3755012A1 (en) 2020-12-23

Similar Documents

Publication Publication Date Title
ES3026565T3 (en) Application-friendly protocol data unit (pdu) session management
US11350336B2 (en) Systems and methods for user plane path selection, reselection, and notification of user plane changes
US11956856B2 (en) Network slice isolation information for session management function discovery
US20250150939A1 (en) Accepting a network slice based on location based network slice coexistence rules