ES2933261T3 - Procedimiento de enrutamiento de datos de una sesión inicializada entre un terminal y un servidor - Google Patents

Procedimiento de enrutamiento de datos de una sesión inicializada entre un terminal y un servidor Download PDF

Info

Publication number
ES2933261T3
ES2933261T3 ES18827208T ES18827208T ES2933261T3 ES 2933261 T3 ES2933261 T3 ES 2933261T3 ES 18827208 T ES18827208 T ES 18827208T ES 18827208 T ES18827208 T ES 18827208T ES 2933261 T3 ES2933261 T3 ES 2933261T3
Authority
ES
Spain
Prior art keywords
session
terminal
server
data
routing
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
ES18827208T
Other languages
English (en)
Inventor
Gaël Fromentoux
Frédéric Fieau
Emile Stephan
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.)
Orange SA
Original Assignee
Orange SA
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 Orange SA filed Critical Orange SA
Application granted granted Critical
Publication of ES2933261T3 publication Critical patent/ES2933261T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/38—Flow based routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/18—Selecting a network or a communication service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/11—Allocation or use of connection identifiers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14—Multichannel or multilink protocols

Landscapes

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

Abstract

La invención se refiere a un método de enrutamiento de datos de una sesión inicializada entre un terminal y un servidor, sobre un primer slot de red correspondiente a un conjunto de funciones informáticas de una infraestructura de comunicaciones, implementadas por el terminal. Este método comprende las etapas de recibir del servidor al menos un identificador de enrutamiento determinado en función de al menos un parámetro de comunicación de la sesión, configurar la información de la sesión en función del al menos un identificador recibido y emitir al servidor los siguientes datos de la sesión enrutados sobre al menos un segundo intervalo correspondiente a la información configurada. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Procedimiento de enrutamiento de datos de una sesión inicializada entre un terminal y un servidor
1. Campo de la invención
La solicitud de invención se sitúa en el campo de las infraestructuras de telecomunicaciones y de las técnicas relativas a segmentos de red (en inglés network slices).
2. Estado de la técnica anterior
Hasta la generación “4G” de red móvil actualmente en curso de despliegue en la mayoría de los países, las diferentes arquitecturas de red se basan, la mayoría de las veces, en equipos muy específicos y dedicados a ciertas funcionalidades precisas, sea cual sea el nivel de la red de acceso o del núcleo de red, en especial en lo que se refiere a la transmisión de paquetes desde o con destino a un terminal móvil. En las infraestructuras de red desplegadas hasta ahora, se utiliza un único conjunto de funciones sea cual sea el tipo de tráfico. Los diferentes flujos de sesiones son por tanto cursadas por un mismo conjunto de funciones (enrutado, direccionado, control de flujos de datos, nombres de dominio,...).
La falta de flexibilidad y de capacidad de evolución inherente a este tipo de arquitectura convencional ha llevado a contemplar la adopción de arquitecturas más flexibles para las próximas generaciones de redes móviles, comenzando por la generación denominada “5G”, con el fin de poder responder rápidamente a las demandas extremadamente diversas en términos de tráfico o de calidad de servicio. Se ha de observar que las redes 5G tienen la vocación de referirse tanto las redes móviles como las redes fijas. Por consiguiente, las técnicas inherentes al desarrollo de las redes 5G se refieren tanto las infraestructuras fijas como las móviles.
Entre las soluciones contempladas, una de las soluciones más prometedoras se basa en una técnica de división por segmentos de la red (“Network Slicing" en inglés).
El 5G en efecto va a tener que soportar casos de uso muy diversos y hará frente a exigencias extremas (por ejemplo, en términos de flujo, eficiencia energética, variedad de equipos, fraccionamiento de los ac to res .) para las cuales la flexibilidad y la capacidad de evolución de las redes serán indispensables. La técnica de “Network Slicing”, que se puede considerar como una técnica que permite implementar instancias específicas de rutas de comunicación en una misma estructura física, la mayoría de las veces a partir de técnicas relativas a la virtualización. Esta técnica permite al operario crear redes adaptadas a las diferentes necesidades (operador, proveedor de servicios, clientes) y proporcionar soluciones que responden a las exigencias diversas que provienen de diferentes sectores del mercado. Estas soluciones se optimizan por ejemplo en términos de funciones de enrutamiento, de rendimiento y de estanqueidad entre aplicaciones o entre clientes.
A día de hoy, según las técnicas conocidas, se contemplan varios métodos para atribuir un segmento de red (o slice en inglés) a un terminal y constituyen el objeto de proposiciones, en especial en normalización (3GPP TR 23.799 v2.0.0 de diciembre de 2016 o Wireless technology evolution towards 5G: 3GPP release 13 to 15 and beyond -5G americas - February 2017 - p 163-167). Se encuentran también ejemplos en los documentos WO2017/200978, US2017/0303259 y EP3343980.
No existen soluciones que atribuyen un slice en función de las soluciones técnicas desplegadas o el curso de despliegue por los proveedores de aplicaciones también denominados terceros en ciertos documentos o “third party en inglés. Estos terceros intervienen tanto en sectores considerados como “verticales” (ciudades inteligentes (en inglés “Smart City’’, san idad,.) en la terminología utilizada en las especificaciones de redes 5G como en la provisión de servicios de comunicación (en inglés “Communication Services Providers" (CS-P)) también denominados Over The Top (OTT). Estos terceros disponen de hecho de su propia infraestructura técnica que permite proporcionar servicios a los clientes a través de Internet y las redes de tipo fijo o móvil. Estas infraestructuras técnicas se componen en especial de servidores, de cachés, de plataformas de servicios de enrutamiento y de procesamiento de flujos, que utilizan soluciones técnicas especializadas o normalizadas. Se ha de señalar que estas infraestructuras técnicas pueden del mismo modo utilizar las técnicas relativas a los “segmentos de red” y asociar un segmento a características de tráfico en especial.
Sin embargo no existe una solución que de una visibilidad de los segmentos a los extremos, terminal un servidor. Por tanto no es posible, por ejemplo, atribuir un segmento en función de características de comunicación de las aplicaciones OTT, por ejemplo en la capa de transporte y/o de aplicación, en un contexto en el que las mismas evolucionan de manera significativa, en especial gracias a las acciones de los terceros.
La presente invención tiene por objeto remediar los inconvenientes de las técnicas utilizadas actualmente.
3. Resumen de la invención
La invención va a mejorar la situación con la ayuda de un procedimiento de enrutamiento de datos de una sesión inicializada entre un terminal y un servidor, en un primer segmento de red correspondiente a un conjunto de funciones de procesamiento de los datos de una infraestructura de comunicación, implementado por el terminal y caracterizado por que comprende las etapas siguientes:
- recepción procedente de un servidor de al menos un identificador de enrutamiento determinado en función de al menos un parámetro de comunicación de la sesión,
- configuración de una información de sesión en función del al menos un identificador recibido,
- emisión con destino al servidor de los datos siguientes de la sesión enrutados en al menos un segundo segmento correspondiente a la información configurada.
Según las técnicas anteriores, la selección dinámica de un segmento de red es realizada o bien por el terminal, en el caso en el que el mismo tiene una información que le permite seleccionar un segmento correspondiente a las características de tráfico, de terminal, de aplicación o de una combinación de estas informaciones, o bien efectuada por el operario de la infraestructura de comunicación. Gracias a esta invención, el servidor remoto detecta que un segmento de red seleccionado para la sesión no se adapta a los parámetros de la comunicación. Se considera en este caso que una sesión puede ser de una sola ruta o de múltiples rutas y se caracteriza por una comunicación de extremo a extremo entre el terminal y el servidor para una o varias aplicaciones. Un parámetro de comunicación de una sesión se caracteriza por una información emitida o recibida por uno o el otro de los extremos de la sesión, en este caso el terminal o el servidor. Un parámetro de comunicación no es específico para una capa del modelo OSI (en inglés Open Systems Interconnection).
El primer segmento elegido por el terminal puede que en especial no esté adaptado ya que los datos de las sesiones no serán procesados por el equipo adecuado durante su enrutamiento. Por tanto estos datos puede que no se beneficien de funciones avanzadas de procesamiento o bien por ejemplo no estén asegurados. El servidor determina por tanto que un nuevo segmento debe utilizarse por el terminal para esta sesión. Esta determinación se realiza en función de parámetros de comunicación, presentes de forma indiferente en los encabezados de los paquetes o de los tramos utilizados para el enrutamiento de los datos o bien en los datos de aplicación de la sesión. Una vez que el servidor ha determinado uno o los nuevos identificadores de enrutamiento, el mismo informa al terminal. Se ha de observar que una sesión puede ser de múltiples rutas y por tanto del mismo modo de segmentos múltiples y que para una sesión, se utilizarán varios segmentos de redes para el enrutamiento de los datos de la sesión. Por ejemplo un segmento se utiliza para los datos de tipo en tiempo real y un segmento para los datos de tipo que no son en tiempo real de la sesión.
El terminal transmite a continuación los datos suplementarios de la sesión modificando estos datos por la configuración de una información de sesión y por tanto permite el enrutamiento de estos datos en uno o varios segmentos diferentes, en función de la información de sesión configurada. Por ejemplo, el terminal puede configurar una información de un campo del protocolo SFC (en inglés Service Function Chaining). Los datos de la sesión son por tanto transmitidos en los segmentos de redes que corresponden al parámetro configurado, afectando el gestor de red a uno o varios segmentos correspondientes a la información configurada. El terminal puede a su vez seleccionar el nuevo segmento de red o los nuevos segmentos de redes. En este caso, la información de sesión es uno o los identificadores de segmentos. Según otro ejemplo, la selección de un segundo o varios segmento(s) de red se realiza por otro dispositivo en el seno de la infraestructura que enruta los datos de la sesión.
Este procedimiento permite por tanto que un terminal pueda enrutar datos de una sesión en función de recomendaciones de un servidor remoto, lo que puede por tanto por ejemplo asegurar un procesamiento específico de los datos de la sesión sin analizar de forma sistemática el contenido de los paquetes o de los segmentos de la sesión, ahorrándole por tanto recursos y permitiendo una rapidez de procesamiento mayor.
Según una característica particular, la sesión es cifrada por el terminal y descifrada por el servidor.
Una sesión cifrada y descifrada por los dos extremos, el terminal y el servidor, hace que los dispositivos intermedios no puedan acceder a ciertas informaciones transmitidas entre el terminal y el servidor. Las informaciones útiles para el enrutamiento de los datos son por tanto generalmente no cifradas mientras que las informaciones relativas a las aplicaciones son cifradas. Como el servidor es el único dispositivo que puede acceder a los datos cifrados, tiene la capacidad de aprovecharlos para intervenir en la elección del segmento de red que enruta los datos en la infraestructura.
Según una característica particular, la sesión se inicializa por el terminal configurando una información de sesión por defecto.
En el caso en el que no se obtenga ninguna información relativa al identificador de enrutamiento por el terminal, los datos de una sesión deben ser sin embargo transmitidos en un primer segmento de la infraestructura de comunicación. Si el terminal no configura ninguna información, el gestor de red de comunicaciones selecciona un primer segmento por defecto. El terminal selecciona por tanto una información por defecto, en correspondencia por ejemplo con la aplicación o el servidor remoto de la sesión, para que los datos de la sesión trasmitidos antes del envío de un identificador de enrutamiento o en ausencia del envío de dicho identificador, se beneficien de un primer segmento de red para el enrutamiento de los datos.
Según una característica particular, la información de la sesión es un dato relativo a una información NSSAI.
La información de la sesión configurada por el terminal puede de forma ventajosa ser relativa a la información NSSAI (Network Slice Selection Assistance Information). Esta información definida en 3GPP (documento TS 23.501, versión 1.5.0, 13 de noviembre de 2017) se puede utilizar de forma ventajosa en especial debido a su probable gran utilización en las redes de comunicación. Por tanto los datos que comprenden esta información NSSAI se pueden enrutar en un segmento de red implementado por un gestor de infraestructura, independientemente de los contratos o relaciones entre el gestor de la infraestructura y el usuario del terminal.
Según una característica particular, el terminal memoriza al menos un identificador recibido en función de los parámetros de comunicación de la sesión.
Con el objetivo de limitar los intercambios entre el servidor y el terminal, el servidor puede de forma ventajosa memorizar los identificadores de enrutamiento recibidos para sesiones anteriores así como los parámetros de comunicación de sesiones correspondientes de manera que aprovecha de nuevo estos identificadores durante una próxima sesión que tenga los mismos parámetros de comunicación. Los primeros datos emitidos pueden por tanto ser enrutados en un segmento de red adaptado a los datos de la sesión configurando una información de sesión correspondiente al identificador memorizado. El servidor podrá sin embargo emitir hacia el terminal otro identificador para esta nueva sesión, en el caso en el que el otro segmento esté más adaptado o si el primer segmento utilizado inicialmente para el enrutamiento de datos presenta por ejemplo problemas.
Los diferentes aspectos del procedimiento de enrutamiento que se acaban de describir pueden implementarse de forma independiente entre sí o en combinación entre sí.
Según un segundo aspecto, la invención se refiere del mismo modo a un procedimiento de determinación del al menos un identificador de enrutamiento de datos de una sesión inicializada entre un terminal y un servidor en un primer segmento de red correspondiente a un conjunto de funciones de procesamiento de datos de una infraestructura de comunicación, implementado por el servidor y caracterizado por que comprende las etapas siguientes:
- determinación de al menos un identificador de enrutamiento en función de al menos un parámetro de comunicación de la sesión,
- emisión con destino al terminal del al menos un identificador determinado,
- recepción procedente del terminal de los datos siguientes de la sesión enrutados en al menos un segundo segmento.
Tras la recepción de los datos emitidos por un terminal, un servidor identifica que el primer segmento de red utilizado para el enrutamiento de datos no está adaptado. En el caso por ejemplo, en el que un conjunto de procesamientos está asociado a un segmento de red, la selección de un primer segmento de red no adaptado por el terminal conduce a que no se apliquen procesamientos a los datos de la sesión. A partir de parámetros de comunicación, tal como una dirección del terminal, un parámetro de calidad de servicio o un parámetro del protocolo de transporte, el servidor constata que uno (o varios) segundo segmento más adaptado debe seleccionarse y determina este nuevo segmento en función de diferentes parámetros. Este procedimiento permite al servidor actualizar dinámicamente una utilización de uno o varios segundos segmentos de red para los datos de una sesión emitidos por un terminal. Este procedimiento puede por ejemplo implementarse para tomar en cuenta problemas que sobrevienen a la infraestructura o para tomar en cuenta nuevas necesidades experimentadas por la entidad encargada del servidor o por una entidad externa que haya expresado una demanda ante el servidor. Además en el caso de sesiones de datos cifradas, el servidor es la única entidad que puede acceder a parámetros de comunicación cifrados, lo que le confiere posibilidades de determinación de identificadores de enrutamiento que los dispositivos intermedios no tienen.
Según una característica particular, al menos un parámetro es relativo a la capa de transporte de la sesión.
La capa de transporte de las redes de comunicación está en una fuerte evolución y comprende cada vez más funciones elementales de procesamiento. Los protocolos de transporte “de múltiples rutas” están además en desarrollo. El servidor puede de forma ventajosa descartar parte de la riqueza funcional de los parámetros de transporte para determinar uno o varios segundos segmentos de red que permitan enrutar los datos en función de estos parámetros. Estos parámetros también son cada vez más cifrados y es interesante para el servidor descartar parte del acceso a estos parámetros que el mismo habrá descifrado para adaptar el procesamiento de los datos determinando un identificador de enrutamiento que permita enrutar los datos en uno o varios segmentos de red. El protocolo TLS (en inglés Transport Layer Security) es en especial uno de los principales protocolos de transporte que asegura un aseguramiento de los datos transmitidos. Los datos transportados en el protocolo TLS son sólo accesibles para el terminal y el servidor, este último puede por ejemplo utilizar los parámetros TLS para determinar un identificador de enrutamiento adaptado a los parámetros del protocolo TLS, estos datos que pueden ser comunes a varias aplicaciones.
Según una característica particular, el al menos un parámetro es relativo al protocolo QUIC.
El protocolo de transporte QUIC (en inglés Quick UDP Internet Connections) especificado en el documento “draft-ietfquic-transport-07’, 13 de octubre de 2017, es un protocolo de transporte cada vez más utilizado en las redes de comunicación. Este protocolo comprende un número importante de informaciones entre las cuales están las informaciones relativas al contexto de conexión múltiple de las informaciones de seguridad así como de las informaciones relativas al flujo de datos. Su riqueza en términos de funciones elementales y su utilización cada vez más importante hacen a este protocolo particularmente pertinente para la determinación de un identificador de enrutamiento.
Según una característica particular, el al menos un parámetro es relativo a la versión del protocolo de la capa de transporte.
Los protocolos de transporte, en especial aquellos en curso de especificación en los organismos de normalización, evolucionan de manera bastante regular a medida que se avanza en las versiones propuestas. Una versión de un protocolo puede por tanto integrar parámetros de calidad de servicio o de seguridad inexistentes en la versión anterior. Este es en particular el caso para las diferentes versiones del protocolo QUIC. Los datos de una sesión pueden por tanto necesitar procesamientos específicos en función de los parámetros característicos de una versión de protocolo. La versión de protocolo puede de forma ventajosa proporcionar información de los procesamientos requeridos y la determinación del identificador de enrutamiento en función de la versión de protocolo puede adaptarse a las necesidades del gestor del servidor.
Según una característica particular, el al menos un identificador es emitido en un dato de un protocolo de transporte.
Para transmitir el identificador de enrutamiento determinado al terminal, el servidor puede utilizar un protocolo de transporte. De hecho, el protocolo de transporte es bastante evolutivo y comprende regularmente nuevas funciones. Este es el caso por ejemplo de los protocolos QUIC o MPTCP (en inglés MultiPath Transport Control Protocol). Además, los protocolos de transporte son protocolos de extremo a extremo, sin modificación posible en el caso en el que el protocolo este cifrado. Parece por tanto interesante transmitir el identificador de enrutamiento en el protocolo de transporte, para que el mismo llegue de forma segura y no codificada al terminal que puede por tanto aprovechar para configurar una información de la sesión.
Los diferentes aspectos del procedimiento de determinación que se acaban de describir pueden implementarse de forma independiente entre sí o en combinación entre sí.
Según un tercer aspecto, la invención se refiere a un dispositivo de enrutamiento de datos de una sesión inicializada entre un terminal y un servidor, en un primer segmento de red correspondiente a un conjunto de funciones de procesamiento de datos de una infraestructura de comunicación, implementado por el terminal y caracterizado por que comprende:
- un receptor, adecuado para recibir procedente del servidor al menos un identificador de enrutamiento determinado en función de al menos un parámetro de comunicación de la sesión,
- un módulo de configuración, adecuado para configurar una información de sesión en función del al menos un identificador recibido,
- un emisor, adecuado para emitir con destino al servidor los datos siguientes de la sesión enrutados en al menos un segundo segmento correspondiente a la información configurada.
Este dispositivo, adecuado para implementar en todos sus modos de realización del procedimiento de enrutamiento que se acaba de describir, está destinado a implementarse en un equipo de extremo, de tipo terminal.
Según un cuarto aspecto, la invención se refiere además a un dispositivo de determinación del al menos un identificador de enrutamiento de datos de una sesión inicializada entre un terminal y un servidor en un primer segmento de red correspondiente a un conjunto de funciones de procesamiento de datos de una infraestructura de comunicación, implementado por el servidor y caracterizado porque comprende:
- un módulo de determinación, adecuado para determinar al menos un identificador de enrutamiento en función de al menos un parámetro de comunicación de la sesión,
- un emisor, adecuado para emitir con destino al terminal el al menos un identificador determinado,
- un receptor, adecuado para recibir procedentes del terminal los datos siguientes de la sesión enrutados en al menos un segundo segmento.
Este dispositivo es adecuado para implementar en todos sus modos de realización el procedimiento de determinación que se acaba de describir. Este dispositivo está destinado a ser implementado en un equipo de extremo, de tipo servidor de datos.
Según un quinto aspecto, la invención se refiere también a un sistema de enrutamiento de datos de una sesión inicializada entre un terminal y un servidor, en un primer segmento de red correspondiente a un conjunto de funciones de procesamiento de datos de una infraestructura de comunicación:
- un terminal que comprende un dispositivo de enrutamiento,
- un servidor que comprende un dispositivo de determinación.
La invención se refiere también a un programa de ordenador que comprende instrucciones para la implementación de las etapas del procedimiento de enrutamiento que se acaba de describir, cuando este programa es ejecutado por un procesador.
La invención se refiere además a un programa de ordenador que comprende instrucciones para la implementación de las etapas del procedimiento de determinación que se acaba de describir, cuando este programa es ejecutado por un procesador.
Este programa puede utilizar cualquier lenguaje de programación y tener la forma de un código fuente, un código objeto o de un código intermedio entre un código fuente y código objeto, tal como en una forma parcialmente compilada o en cualquier otra forma deseable.
La invención tiene por objetivo también un soporte de informaciones legible por un ordenador y que comprende instrucciones de programas de ordenador tales como las mencionadas anteriormente.
El soporte de informaciones puede ser cualquier entidad o dispositivo capaz de almacenar los programas. Por ejemplo, el soporte puede comprender un medio de almacenamiento, tal como una ROM, por ejemplo un CD ROM o una ROM de circuito microelectrónico o incluso un medio de grabación magnético, por ejemplo un disquete (floppy disk) o un disco duro.
Por otro lado, el soporte de informaciones puede ser un soporte transmisible tal como una señal eléctrica u óptica, que puede transmitirse a través de un cable eléctrico u óptico, por radio o por otros medios. El programa según la invención puede ser en particular descargado de una red de tipo Internet.
De forma alternativa, el soporte de informaciones puede ser un circuito integrado en el cual el programa está incorporado, el circuito que está adaptado para ejecutar o para ser utilizado en la ejecución de los procedimientos en cuestión.
4. Presentación de las figuras
Otras ventajas y características de la invención aparecerán más claramente de la lectura de la descripción siguiente de un modo de realización particular de la invención, dado a título de simple ejemplo ilustrativo y no limitativo y de los dibujos adjuntos, entre los cuales:
- la figura 1 presenta una vista simplificada de una infraestructura de comunicaciones que implementa el procedimiento de enrutamiento de datos según un aspecto de la invención,
- la figura 2 representa una vista general del procedimiento de enrutamiento de datos, según un primer modo de realización de la invención,
- la figura 3 presenta una vista general del procedimiento de enrutamiento de datos, según un segundo modo de realización de la invención,
- la figura 4 presenta una vista general del procedimiento de enrutamiento de datos, según un tercer modo de realización de la invención,
- la figura 5 presenta un ejemplo de estructura de un dispositivo de enrutamiento según un aspecto de la invención,
- la figura 6 presenta un ejemplo de estructura de un dispositivo de determinación según un aspecto de la invención.
5. Descripción detallada de al menos un modo de realización de la invención
En el resto de la descripción, se presentan ejemplos de varios modos de realización de la invención en una infraestructura de comunicación, que puede ser fija y/o móvil.
En primer lugar nos referimos a la figura 1 que presenta una vista simplificada de una infraestructura de comunicaciones que implementa el procedimiento de enrutamiento de datos según un aspecto de la invención.
En la figura 1, dos terminales 51 y 53 están conectados a una infraestructura 10 de comunicaciones. En el terminal 51, tres aplicaciones App1, App2 y App3 están activadas. Los flujos de datos relativos a las aplicaciones App1 y App2 están enrutados por una capa de transporte Trans1. Los flujos de datos de la aplicación App3 del terminal 51 están enrutados en otra capa de transporte Trans2. Las capas de transporte Trans1 y Trans2 pueden ser completamente distintas, es decir basadas en protocolos diferentes, como por ejemplo TCP (en inglés Transport Control Protocol) y UDP (en inglés User Datagram Protocol). Según otro ejemplo, las dos capas de transporte Trans1 y Trans2 pueden ser versiones diferentes de un mismo protocolo, como por ejemplo QUIC versión 1 y QUIC versión 2. Según otro ejemplo más, Trans1 y Trans2 pueden ser una misma versión de protocolo pero con configuraciones diferentes. En el terminal 53, las aplicaciones App4 y App5 cuyos flujos de datos son respectivamente enrutados por las capas de transporte Trans4 y Trans3. En el resto del documento, los datos de una aplicación App1 en una capa de transporte Trans1 serán denominados los datos App1/Trans1.
Se considera que la aplicación App1/Trans1 del terminal 51 establece una sesión de datos con el servidor 40 instalado en una red 42 local. El servidor puede por ejemplo ser un servidor HTTP (en inglés HyperText Transfer Protocol) y la infraestructura 42 local una granja de servidores. La aplicación App2/Trans1 establece una sesión con el servidor 40. La aplicación App3/trans2 establece una sesión con el servidor 40. La aplicación App5/trans3 establece una sesión de datos con el servidor 50 de la red 52 local. La aplicación App4/Trans4 establece una sesión con el servidor 60 de la red 62 local. La red 42 local, como las redes 52 y 62, pueden además comprender dispositivos de procesamiento de los flujos de datos tales como cortafuegos o funciones de optimización, de manera no limitativa.
La infraestructura 10 de comunicaciones está organizada en segmentos que permiten a los flujos de datos que tengan características comunes en términos de enrutamiento, de calidad de servicio o de seguridad, ser enrutados en un mismo segmento. Se ha de observar que la estructuración de los segmentos y la asociación de los flujos de datos en los diferentes segmentos son de responsabilidad del gestor de la infraestructura 10 de comunicaciones. Los segmentos de la infraestructura pueden, según una alternativa, ser únicamente implementados en la infraestructura 10 o bien ser instanciados en la infraestructura 10 y los terminales 51 y 53 y/o las redes 42, 52, 62 locales. En la figura 1, se considera que los flujos App1/Trans1 de datos son enrutados hacia el servidor 40 en un segmento Tr1 de red. Los flujos App2/Trans2 de datos y los flujos App3/Trans2 de datos son enrutados en un segmento TR2 hacia el mismo servidor 40. Los flujos App5/Trans3 de datos son enrutados hacia el servidor 40 en un segmento TR3 y los flujos App4/Trans4 hacia el servidor 60 en un segmento TR4.
Se ha de observar además que un mismo servidor puede albergar varias aplicaciones, como es el caso en la figura 1 para el servidor 40 que alberga las aplicaciones App1, App2 y App3. Los segmentos de red utilizados pueden ser específicos de la infraestructura 10. En este caso, el gestor no transmite informaciones en los segmentos de red de la infraestructura a los terminales ni a los servidores. En el caso en el que por ejemplo el gestor de la infraestructura 10 sea también el gestor de un terminal y/o de un servidor o bien que se establezca un contrato entre los gestores respectivos, un terminal y/o un servidor puede tener conocimiento de los segmentos desplegados por el gestor de la infraestructura 10.
En relación con la figura 2, se presenta una vista general del procedimiento de enrutamiento de datos, según un primer modo de realización de la invención.
El esquema sinóptico de la figura 2 tiene por objetivo describir de manera genérica las fases de implementación del procedimiento en una infraestructura de comunicaciones. Durante una fase P1, un terminal inicia una sesión con un servidor. Se puede tratar de una sesión de aplicación de tipo HTTP, FTP (en inglés File Transfer Protocol) o de manera no limitativa, una sesión P2P (en inglés Point-to-Point).
Por defecto, durante la inicialización de la sesión, el terminal no dispone de información de sesión enviada por el servidor, el terminal configura una información de sesión por defecto en los mensajes enviados hacia el servidor. Según un ejemplo, esta información de sesión puede también ser la última información obtenida del servidor. Esta información puede ser un campo específico de un protocolo de encadenado de servicios, tal como SFC (en inglés Service Function Chaining) o de un dato añadido en un protocolo, por ejemplo de transporte o de aplicación, que puede ser aprovechado por la infraestructura de comunicación que enruta los datos hacia el servidor.
Si la información de sesión no se puede aprovechar directamente para enrutar los datos de la sesión en un fragmento, la misma se interpreta por tanto por un dispositivo de la red, encargado de dirigir los flujos de diferentes sesiones en los segmentos de la infraestructura de comunicación. Este dispositivo, tras la recepción de los datos de sesión trasmitidos por el terminal, establece una correspondencia entre la información de sesión y un segmento, para transmitir los datos de la sesión en un segmento, denominado primer segmento. Los datos de la sesión son en este caso enrutados en un primer segmento por defecto de acuerdo con la información por defecto configurada por el terminal. En el ejemplo descrito, el terminal añade una información de sesión NSSAI1 y el dispositivo de infraestructura de comunicación añade un identificador de primer segmento, correspondiente a la información de sesión NSSAI1 configurada por el terminal. El mismo lo añade por ejemplo en un campo del protocolo de trasporte utilizado para el enrutamiento de los datos de la sesión.
Durante la fase P2, el servidor recibe los datos de la sesión emitidos por el terminal durante la fase P1 y determina que un nuevo identificador de enrutamiento debe ser utilizado por el terminal para los datos restantes de la sesión. Para determinar que un nuevo identificador de enrutamiento deberá ser utilizado por el terminal, el servidor analiza los parámetros de comunicación de la sesión. Entre estos parámetros, el servidor identifica por ejemplo la información NSSAI1 de sesión añadida por el terminal así como posiblemente otros campos del protocolo de transporte y/o de los campos del protocolo de aplicación cuyos diferentes ejemplos serán dados en las figuras 3 y 4. El mismo se puede utilizar también para la determinación de un identificador, el identificador de primer segmento utilizado por la infraestructura de comunicación en el caso en el que este identificador le sea comunicado.
Durante la fase P3, el servidor determina un identificador de enrutamiento correspondiente a los parámetros analizados durante la fase P2. El gestor del servidor habrá tenido anteriormente conocimiento de los segmentos de red utilizados en la red de comunicación que enrutan los datos de la sesión así como de sus características. El servidor selecciona al menos un identificador de enrutamiento cuyas características corresponden a los parámetros de la sesión y le transmite al terminal. El identificador de enrutamiento puede ser un identificador de segmento de la infraestructura de comunicación pero puede también ser un identificador de enrutamiento propio del servidor y del terminal para el cual se debe efectuar una correspondencia con un identificador de segmento de la infraestructura de comunicación. El servidor transmite el identificador al terminal en un campo de un protocolo utilizado por la sesión o bien transmite esta información utilizando un protocolo específico. Si la sesión es una sesión de tipo HTTP/TCP, el servidor puede reenviar la información en el protocolo HTTP o el protocolo TCP, incluso utilizar un protocolo diferente.
Tras la recepción del nuevo identificador transmitido por el servidor, durante la fase P4, el terminal configura una nueva información NSSAI2 de sesión, correspondiente al identificador de enrutamiento recibido. Según un ejemplo, la información de sesión puede ser idéntica al identificador de enrutamiento. También puede tratarse de una información que se va a actualizar en un protocolo, tal como por ejemplo un parámetro de calidad de servicio. Los datos de la sesión en adelante se emiten con esta información de sesión actualizada.
Durante la fase P5, el terminal emite los datos de la sesión con la información de sesión actualizada, permitiendo a los datos de la sesión ser enrutados en un segundo segmento de red correspondiente a las características de la sesión, estas características que son formalizadas con la información de sesión. La información de sesión es interpretada por un dispositivo de la red y el dispositivo añade un identificador de segundo segmento a los datos transportados en la infraestructura de comunicación, que le permiten ser enrutados en un segmento adaptado a las características de la sesión durante la fase P6.
Se ha de observar que el servidor y el dispositivo de infraestructura de comunicación seleccionan posiblemente un identificador de enrutamiento y de segundo segmento en función de una información de sesión. Por tanto es necesario que estas dos entidades se coordinen con anterioridad para que sus selecciones respectivas sean coherentes.
Nos referimos ahora a la figura 3 que representa una vista general del procedimiento de enrutamiento de datos, según un segundo modo de realización de la invención.
Durante una fase de inicialización del procedimiento, el servidor 50 App1 emite durante una etapa E1 emite un mensaje hacia un dispositivo 80 Acc1 de la infraestructura 10 de comunicación para comunicarle en un mensaje M0 los identificadores de enrutamiento que el dispositivo 80 debe interpretar para enrutar los datos de las sesiones de datos hacia el servidor 50. Con fines de simplificación, el mensaje M0 se transmite directamente al dispositivo 80 en la figura 3. Según una alternativa, el mensaje M0 puede enviarse a un servidor de gestión de la infraestructura 10 que a su vez transmitirá esta información a los diferentes dispositivos de acceso de la infraestructura 10, en especial para evitar a los diferentes servidores que comuniquen directamente con los dispositivos de acceso. El mensaje M0 puede además comprende características de sesiones relativas a los identificadores de enrutamiento de tal manera que el dispositivo 80 puede seleccionar un segmento de red adaptado a las características de las sesiones. Según un ejemplo, los identificadores de enrutamiento pueden corresponder con identificadores de segmentos utilizados en la infraestructura de comunicación y/o con datos relativos a opciones de enrutamiento, por ejemplo cuando se utilizan arquitecturas de tipo CDN (en inglés Content Delivery Networks). Tras la recepción del mensaje M0 durante la etapa E2, el dispositivo 80 es capaz de enrutar los datos de las sesiones con destino al servidor 50 en los segmentos de red de la infraestructura de comunicación.
De manera correspondiente, el servidor 40 App2 emite un mensaje M'0 al dispositivo 90 durante una etapa E3 que el dispositivo 90 recibe durante una etapa E4. El servidor 40 es por tanto capaz de enrutar los datos con destino al servidor 40. Con fines de simplificación, los intercambios no se representan en la figura pero los servidores 50 y 40 respectivos informan del mismo modo respectivamente a los dispositivos 90 y 80 de manera correspondiente.
Durante una etapa E5, el terminal 51 Term1 se graba en la infraestructura de comunicación transmitiendo un mensaje M1 al dispositivo 90. El terminal 51 informa al dispositivo 90 en este mensaje sobre la información de sesión por defecto utilizada de manera que un segmento de red por defecto se ha afectado previamente por el dispositivo 90. El dispositivo 90, tras la recepción del mensaje M1 durante la etapa E6, comunica esta información a otros dispositivos de manera que cualquier dispositivo que reciba los datos del terminal sea capaz de asociar el segmento de red por defecto.
Durante una etapa E7, el terminal 51 emite un mensaje M2 con destino al servidor 40 App2. Este mensaje M2 es un mensaje HELLO de tipo HTTP/QUIC/UDP/IP. El mensaje M2 es enrutado en la infraestructura 10 de comunicación de acuerdo con la información de sesión por defecto añadida por el terminal 51 para el cual el dispositivo 90 de la infraestructura de comunicación asocia un segmento. El mensaje M2, transmitido inicialmente al dispositivo 90 que lo retransmite a continuación al servidor 40, comprende informaciones de transporte del protocolo QUIC entre las cuales está una información relativa a la versión del protocolo QUIC utilizada así como una versión de algoritmo de compresión de la señalización. Basándose en estos datos recibidos, el servidor 40 App2 detecta que la versión del protocolo QUIC utilizada no es conveniente, por ejemplo ya que existe una nueva versión o porque no es apropiada para la aplicación. El servidor desea además que los datos siguientes emitidos desde el terminal sean transportados en un segundo segmento de red más adaptado a las características de la aplicación. Según una alternativa, el servidor 40 aprovecha informaciones de tipo meta datos, por ejemplo de tipo CDNI (en inglés Content Distribution Network Information) presentes en los datos enrutados por el protocolo QUIC para determinar el identificador de enrutamiento. Los datos pueden ser relativos al protocolo QUIC o bien ser datos de aplicación enrutados gracias al protocolo QUIC. La información de sesión presente en el mensaje M2 y correspondiente en este caso a la versión QUIC debe por tanto modificarse por el terminal 51. El servidor 40 determina durante una etapa E9 un nuevo identificador de enrutamiento que permite a los datos de la sesión ser enrutados en un segundo segmento de la red de comunicación 10 más adaptado.
Según un ejemplo, en el caso en el que el identificador de enrutamiento enviado al terminal 51 no se ha comunicado al dispositivo 90 durante la etapa E3, el servidor lo transmite en un mensaje M3 al dispositivo 90 durante una etapa E10, así como las características asociadas a este identificador, para asegurarse de que los datos que tengan características correspondientes a este identificador sean enrutados en un segundo segmento de red adecuado. El dispositivo 90, tras la recepción de este mensaje durante la etapa E11, es capaz de enrutar los datos de la sesión, actualizados por el terminal en función del identificador de enrutamiento recibido, en un segundo segmento de red de la infraestructura 10.
Durante una etapa E12, el servidor 40 transmite un mensaje M4 con destino al terminal 51 que comprende un identificador de enrutamiento. Por tanto, los datos siguientes de la sesión inicializada por el terminal 51 a través del envío del mensaje M2 son enrutados en un segundo segmento de red en adecuación con las características de la sesión. El servidor 40 transmite, según este ejemplo, un mensaje HTTP/QUIC/UDP/IP que comprende una información sobre el identificador de enrutamiento que se va utilizar para la sesión, el identificador que se inserta en un dato del protocolo QUIC. En este ejemplo, el servidor 40 transmite una información sobre el NSSAi al terminal 51 que la recibe durante la etapa E13. El servidor 40 indica además al terminal en el mensaje M4 que utilice una versión más reciente del protocolo QUIC. El identificador de enrutamiento estará constituido por la información NSSAI y por la versión del protocolo QUIC que se va a utilizar.
Durante una etapa E14, el terminal 51 configura una información de sesión en función del identificador de enrutamiento recibido en el mensaje M4. Según un ejemplo, el terminal 51 actualiza la versión del protocolo QUIC de acuerdo con el contenido del mensaje M4 e inserta el identificador NSSAI en un dato del protocolo QUIC. En este ejemplo, la información de sesión es idéntica al identificador de enrutamiento recibido pero según otros ejemplos, la información de sesión puede ser diferente del identificador de enrutamiento recibido. En el caso especial en el que el terminal 51 no puede insertar la información NSSAI recibida, ya que no soporta dicha opción, el mismo actualiza la versión de QUIC y posiblemente inserta además una información suplementaria por ejemplo en un campo de mensaje transmitido, por ejemplo un campo Flow Labely/o Traffic Class del encabezado de datagramas IPv6 o el campo Type de servicio del encabezado de datagrama IPv4.
Durante una etapa E15, el terminal 51 actualiza su grabación en la infraestructura de comunicación transmitiendo un mensaje M5 al dispositivo 90. El terminal 51 informa al dispositivo 90 en este mensaje sobre la información de sesión configurada durante la etapa E14 de manera que un segundo segmento de red este afectado por el dispositivo 90. El dispositivo 90, tras la recepción del mensaje M5 durante la etapa E16, comunica esta información a los otros dispositivos de la infraestructura 10 de manera que sea cual sea el dispositivo que recibe los datos del terminal sea capaz de asociar el segundo segmento de red asociado a la información de sesión. Esta comunicación a los otros dispositivos puede realizarse, según una alternativa, a través de un servidor 70 de gestión de la infraestructura 10 que se encargara a continuación de informar a los diferentes dispositivos de acceso. Según esta alternativa, el dispositivo 90 transmite durante la etapa F1 un mensaje G1 que comprende la información de sesión al servidor 71 de gestión que, una vez que la recibe durante la etapa F2, la retransmite al dispositivo 80 durante una etapa F3. El dispositivo 80 recibe el mensaje G1 en la etapa F4 y es capaz de asociar un segundo segmento a un mensaje que comprende la información de sesión procedente del terminal 51.
Según una alternativa, el dispositivo 90 informa durante la etapa E17 al servidor 40 de la actualización del segundo segmento de red para los datos de la sesión transmitiendo un mensaje M6. Este mensaje M6 comprende la información de sesión configurada por el terminal 51 y el segmento asociado, lo que permite al servidor 40 asegurarse por un lado de que el dispositivo 40 enruta los datos de la sesión en un segmento adaptado y por otro lado conocer la información de sesión configurada por el terminal 51 para la sesión.
Durante una etapa E19, según una alternativa, el terminal memoriza el identificador de enrutamiento recibido para la sesión. Esta memorización permite al terminal configurar directamente una información de sesión adaptada, al lanzamiento de una nueva sesión que presentaría parámetros de comunicación idénticos al anterior. Por tanto los primeros datos de esta nueva sesión son directamente enrutados en un segmento de red correspondiente a las características de esta nueva sesión.
Durante la etapa E20, el terminal 51 transmite los datos de la sesión en un mensaje M7 al servidor 40, estos datos que son actualizados con la información de sesión configurada por el terminal 51. Estos datos se transmiten a través de la infraestructura 10 de comunicación y de forma más precisa el dispositivo 90, que enruta los datos de la sesión en un segundo segmento de red adaptado a las características de la sesión hasta el servidor 40.
Según una alternativa, cuando el dispositivo 90 de la infraestructura asocia un segmento a una información de sesión del mensaje M7 transmitido por el terminal, guardan memoria los datos del mensaje M7 recibido para poder asociar el mismo segmento a sesiones que tendrán los mismos datos. Por ejemplo, el dispositivo 90 puede guardar en memoria los datos del mensaje M7 (origen de dirección IP, destino de dirección IP, origen de puerto, destino de puerto, protocolo, versión, identificador de segmento, tique de sesión TLS, identificador de conexión QUIC) con el objetivo de poder asociar mensajes al segmento seleccionado. Por ejemplo, ciertos mensajes QUIC que utilizan encabezados cortos no poseen el campo de versión, pero podrían sin embargo estar asociados al segmento seleccionado por el mensaje M7 gracias a la memorización de los datos asociados al segmento durante una sesión anterior por ejemplo. Además, los datos memorizados pueden del mismo modo ser de forma ventajosa utilizados para la atribución de un segmento a mensajes emitidos por el servidor 40 con destino al terminal 51.
El servidor 40, tras la recepción del mensaje M7 durante la etapa E21, recibe los datos de la sesión emitidos por el terminal 51 y verifica la información de sesión configurada por el terminal correspondiente al identificador de enrutamiento transmitido en el mensaje M4, si es necesario refiriéndose además al mensaje M6. Según este modo de realización, el servidor E21 verifica la versión del protocolo QUIC y la información NSSAI correspondiente a las informaciones que ha transmitido anteriormente.
Nos referimos ahora a la figura 4 que presenta una vista general del procedimiento de enrutamiento de datos, según un tercer modo de realización de la invención.
Las etapas E1 a E5 son idénticas a las etapas correspondientes de la figura 3. Durante la etapa E'5, el terminal 53 Term2 se graba en el dispositivo 80 Acc2 enviando un mensaje M'1. Este mensaje de grabación permite, en el caso de una red 5G, en especial al terminal 53 grabarse en la NGRAn (en inglés New Generation Radio Access Networks) y, tras la recepción del mensaje M'1 en la etapa E'6, a la NGRAN seleccionar un dispositivo de AMF (en inglés Access and Mobility Management Function) de acuerdo con la especificación 3GPP TR 23.799 (versión 14.016/12/2016).
Durante la etapa E'7, el terminal 53 transmite un mensaje M'2 con destino al servidor 50 Serv App2. El mensaje M'2 es un mensaje de tipo (HTTP/2)/TLS/IP. Tras la recepción del mensaje M'2 el servidor 50 analiza los parámetros de comunicación del mensaje M'2. En especial, el mismo examina los parámetros del protocolo de transporte TLS y los parámetros del protocolo HTTP2 del mensaje M'2 emitido por el terminal 53.
Los parámetros de comunicación del protocolo TLS, tales como los definidos en la sección 5 del documento IETF RFC 8095 (marzo de 2017) así como en el documento IETF https://tools.ietf.org/html/draft-pauly-taps-transport-security-00 (03/07/2015) se analizan en especial. Los parámetros HTTP/2, tales como los definidos en el documento IETF RFC 7540 (mayo de 2015) se analizan del mismo modo por el servidor tras la recepción del mensaje M'2 durante la etapa E'8. Se ha de observar además que el terminal 53 ha utilizado un identificador de primer segmento de red por defecto para emitir el mensaje M'2. Según esta alternativa, el terminal 53 inserta a su vez un identificador de primer segmento de red que la infraestructura 10 de comunicación es capaz de aprovechar para enrutar los datos emitidos por el terminal 53.
Durante la etapa E'9, el servidor ha analizado los diferentes parámetros y ha constatado que el segmento de red que ha enrutado el mensaje M'2 y por tanto que ha obtenido el identificador en el mensaje M'2, no se ha adaptado a ciertos parámetros de TLS y/o HTTP/2 del mensaje M'2. El servidor 50 determina, a partir de los parámetros, un nuevo identificador de enrutamiento para los próximos mensajes que se van a emitir por el terminal 53 para esta sesión (HTTP/2)/TLS/IP. Según este ejemplo, el identificador de enrutamiento determinado toma en cuenta los parámetros por ejemplo de cifrado (TLS), de control de flujo (en inglés Flow control) y de multiplexado de los flujos de aplicación HTTP/2 de compresión. Según otro ejemplo, y con el fin de optimizar la determinación de un identificador de enrutamiento, el servidor 50 sólo considera las versiones de los protocolos para determinar un identificador de enrutamiento ya que a una versión de protocolo corresponde un conjunto de parámetros. Refiriéndose a una versión de protocolo en el mensaje M'2 recibido del terminal 53, el servidor 50 sabe que un cierto número de parámetros, entre aquellos definidos en los documentos citados anteriormente, están presentes o no en el mensaje M'2.
Las etapas E'10 a E'13 son equivalentes a las etapas E10 a E13 de la figura 3 con la diferencia de que el mensaje M'4 comprende un identificador de enrutamiento que comprende un identificador de segmento de red 10 de comunicación así como los parámetros de comunicación a actualizar por el terminal. Según una alternativa, el servidor 50 puede determinar varios identificadores de enrutamiento para que los datos emitidos por el terminal se han enrutados en varios segmentos de red, denominados segundos segmentos, en el seno de la infraestructura de comunicación. Esta alternativa está motivada en especial por el desarrollo de protocolos de múltiples rutas y la posibilidad para los terminales de estar conectados de forma simultánea a varias infraestructuras de comunicación.
El terminal 53, tras la recepción del mensaje M'4 durante la etapa E'13 configura el identificador de segundo segmento recibido en el mensaje M'4 en los mensajes de la sesión de datos que se van a emitir hacia el servidor 50. Este identificador de segundo segmento reemplaza el identificador del primer segmento utilizado inicialmente por defecto. El terminal 53 actualiza del mismo modo los parámetros de comunicación transmitidos por el servidor 50. Esta actualización es facultativa. De hecho, el terminal en el caso en el que no es adecuado para utilizar estos parámetros, no podrá configurarlos en los mensajes a emitir.
Las etapas E'15 a E'19 corresponden a las etapas E15 a E19 de la figura 3.
Durante la etapa E'20 el terminal 53 se emite los datos de la sesión hacia el servidor 50, aquellos que hayan sido configurados con el identificador de segundo segmento de red de la infraestructura 10 de comunicación recibido del servidor 50. Este modo de realización se implementa en especial en el caso en el que el terminal 53 y el servidor 50, por un lado, y la infraestructura 10 de comunicación estén administrados por un solo gestor o bien que exista una colaboración entre los gestores del terminal 53, el gestor del servidor 50 y el gestor de la infraestructura 10. Según una alternativa, el terminal 53 tiene la capacidad de gestionar varios segmentos de red y transmitir los datos de la sesión en el o los segundo(s) segmentos de red cuyo identificador (o identificadores) le ha(n) sido comunicado(s) por el servidor 50.
Los modos de realización de las figuras 2, 3, 4 no son exclusivos y se pueden contemplar combinaciones de estos modos.
En relación con la figura 5, se presenta un ejemplo de estructura de un dispositivo de enrutamiento, según un aspecto de la invención.
El dispositivo 100 de enrutamiento implementa el procedimiento de enrutamiento, cuyos diferentes modos de realización se acaban de describir.
Dicho dispositivo 100 puede implementarse en un terminal o de forma más global en un dispositivo de acceso a una infraestructura (terminal fijo, terminal móvil, box). El dispositivo de acceso puede ser un equipo para una clientela residencial o clientela profesional, conectado a una red fija o a una red móvil.
Por ejemplo, el dispositivo 100 comprende una unidad 106 de procesamiento, equipada por ejemplo de un microprocesador |jP y controlada por un programa 105 de ordenador almacenado en una memoria 107 y que implementa el procedimiento de enrutamiento según la invención. Al inicio, las instrucciones de código del programa 105 de ordenador son por ejemplo cargadas en una memoria RAM, antes de ser ejecutadas por el procesador de la unidad 106 de procesamiento.
Dicho dispositivo 100 comprende:
- un receptor 120, adecuado para recibir procedente del servidor al menos un identificador de enrutamiento determinado en función de al menos un parámetro de comunicación de la sesión,
- un módulo 101 de configuración, adecuado para configurar una información de sesión en función del al menos un identificador recibido,
- un emisor 110, adecuado para emitir con destino al servidor los datos siguientes de la sesión enrutados en al menos un segundo segmento correspondiente a la información configurada.
En relación con la figura 6, se presenta un ejemplo de estructura de un dispositivo de determinación, según un aspecto de la invención.
El dispositivo 200 de enrutamiento implementa el procedimiento de determinación cuyos diferentes modos de realización se acaban de describir.
Dicho dispositivo 200 puede implementarse en un servidor o de forma más amplia en un dispositivo de extremo con capacidad de establecer una sesión con un terminal.
Por ejemplo, el dispositivo 200 comprende una unidad 206 de procesamiento, equipada por ejemplo de un microprocesador j P y controlada por un programa 205 de ordenador, almacenado en una memoria 207 y que implementa el procedimiento de enrutamiento según la invención. Al inicio, las instrucciones de código del programa 205 de ordenador son por ejemplo cargadas en una memoria RAM, antes de ser ejecutadas por el procesador de la unidad 206 de procesamiento.
Dicho dispositivo 200 comprende:
- un módulo 201 de determinación, adecuado para determinar al menos un identificador de enrutamiento en función de al menos un parámetro de comunicación de la sesión,
- un emisor 210, adecuado para emitir con destino al terminal el al menos un identificador determinado,
- un receptor 220, adecuado para recibir procedentes del terminal los datos siguientes de la sesión enrutados en al menos un segundo segmento.
La implementación del procedimiento de enrutamiento y del procedimiento de determinación es válida para cualquier tipo de infraestructura, fija o móvil y comprendida en la misma para las redes híbridas, fijas y móviles, cuando un terminal se conecta de forma simultánea una infraestructura fija y a una infraestructura móvil. Una sesión de múltiples rutas permite en especial mejorar la velocidad de transmisión de datos así como la fiabilidad de enrutamiento de los datos. El procedimiento de enrutamiento permite la implementación de arquitecturas de múltiples rutas y permite seleccionar un segmento de red que se basa en varias rutas diferentes o bien varios segmentos de red, cada segmento que permite el enrutamiento de los datos en una o varias rutas.
También es posible afectar un segmento de red a un terminal para una sesión dada independientemente del tipo de red comprendida en el mismo si el terminal está multiconectado. Además de la multiconexión, otra tendencia de evolución de las infraestructuras se refiere a la confidencialidad de las comunicaciones y por tanto al cifrado de los datos. Este procedimiento se adapta particularmente a este contexto ya que los dispositivos intermedios, sino algunas excepciones y para necesidades en general relacionadas con las funciones de seguridad desplegadas por los administradores, no pueden acceder a las informaciones denominadas útiles transmitidas por los terminales y/o los servidores. El procedimiento de enrutamiento, basado en la contribución de un terminal y de un servidor para la afectación de un segmento de red o tráfico dado se adapta completamente a un contexto de comunicaciones cifradas. Los dispositivos intermedios que enrutan el tráfico contribuyen sin embargo al procedimiento por los intercambios con el terminal y/o el servidor pero sin tener necesidad de descifrar los datos transmitidos en un campo de datos cifrado y destinado a uno solo o varios destinatarios bien definidos.

Claims (15)

  1. REIVINDICACIONES
    I. Procedimiento de enrutamiento de datos de una sesión inicializada entre un terminal y un servidor, en un primer segmento de red correspondiente a un conjunto de funciones de procesamiento de datos de una infraestructura de comunicación, implementado por el terminal y caracterizado por que comprende las etapas siguientes:
    - recepción procedente del servidor de al menos un identificador de enrutamiento determinado en función de al menos un parámetro de comunicación de la sesión,
    - configuración de una información de sesión en función del al menos un identificador recibido,
    - emisión con destino al servidor de los datos siguientes de la sesión enrutados en al menos un segundo segmento correspondiente a la información configurada.
  2. 2. Procedimiento de enrutamiento, según la reivindicación 1, en el que la sesión es cifrada por el terminal y descifrada por el servidor.
  3. 3. Procedimiento de enrutamiento, según la reivindicación 1, en el que la sesión es inicializada por el terminal configurando una información de sesión por defecto.
  4. 4. Procedimiento de enrutamiento, según la reivindicación 1, en el que la información de la sesión es un dato relativo a una información NSSAI.
  5. 5. Procedimiento de enrutamiento, según la reivindicación 1, en el que el terminal memoriza al menos un identificador recibido en función de los parámetros de comunicación de la sesión.
  6. 6. Procedimiento de determinación de al menos un identificador de enrutamiento de datos de una sesión inicializada entre un terminal y un servidor en un primer segmento de red correspondiente a un conjunto de funciones de procesamiento de datos de una infraestructura de comunicación, implementado por el servidor y caracterizado por que comprende las etapas siguientes:
    - determinación de al menos un identificador de enrutamiento en función de al menos un parámetro de comunicación de la sesión,
    - emisión con destino al terminal del al menos un identificador determinado,
    - recepción procedente del terminal de los datos siguientes de la sesión enrutados en al menos un segundo segmento.
  7. 7. Procedimiento de determinación, según la reivindicación 6, en el que al menos un parámetro es relativo a una capa de transporte de la sesión.
  8. 8. Procedimiento de determinación, según la reivindicación 6, en el que al menos un parámetro es relativo al protocolo QUIC.
  9. 9. Procedimiento de determinación, según la reivindicación 6, en el que al menos un parámetro es relativo a la versión de protocolo de la capa de transporte.
  10. 10. Procedimiento de determinación, según la reivindicación 6, en el que al menos un identificador es emitido en un dato de un protocolo de transporte.
  11. I I . Dispositivo de enrutamiento de datos de una sesión inicializada entre un terminal y un servidor en un primer segmento correspondiente a un conjunto de funciones de procesamiento de datos de una infraestructura de comunicación, implementado por el terminal y caracterizado porque comprende:
    - un receptor, adecuado para recibir procedente del servidor al menos un identificador de enrutamiento determinado en función de al menos un parámetro de comunicación de la sesión,
    - un módulo de configuración, adecuado para configurar una información de sesión en función del al menos un identificador recibido,
    - un emisor, adecuado para emitir con destino al servidor los datos siguientes de la sesión enrutados en al menos un segundo segmento correspondiente a la información configurada.
  12. 12. Dispositivo de determinación de al menos un identificador de enrutamiento de datos de una sesión inicializada entre un terminal y un servidor en un primer segmento de red correspondiente a un conjunto de funciones de procesamiento de datos de una infraestructura de comunicación, implementado por el servidor y caracterizado por que comprende:
    - un módulo de determinación, adecuado para determinar al menos un identificador de enrutamiento en función de al menos un parámetro de comunicación de la sesión,
    - un emisor, adecuado para emitir con destino al terminal el al menos un identificador determinado,
    - un receptor, adecuado para recibir procedentes del terminal los datos siguientes de la sesión enrutados en al menos un segundo segmento.
  13. 13. Sistema de enrutamiento de datos de una sesión inicializada entre un terminal y un servidor, en un primer segmento de red correspondiente a un conjunto de funciones de tratamiento de datos de una infraestructura de comunicación: - un terminal que comprende un dispositivo de enrutamiento según la reivindicación 11,
    - un servidor que comprende un dispositivo de determinación según la reivindicación 12.
  14. 14. Programa de ordenador, caracterizado porque comprende instrucciones para la implementación de las etapas del procedimiento de enrutamiento según la reivindicación 1, cuando este procedimiento es ejecutado por un procesador.
  15. 15. Soporte de grabación legible por un dispositivo de enrutamiento de acuerdo con la reivindicación 11, en el que se graba el programa según la reivindicación 14.
ES18827208T 2017-12-01 2018-11-29 Procedimiento de enrutamiento de datos de una sesión inicializada entre un terminal y un servidor Active ES2933261T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1761552A FR3074626A1 (fr) 2017-12-01 2017-12-01 Procede d'acheminement de donnees d'une session initialisee entre un terminal et un serveur
PCT/FR2018/053047 WO2019106308A1 (fr) 2017-12-01 2018-11-29 Procédé d'acheminement de données d'une session initialisée entre un terminal et un serveur

Publications (1)

Publication Number Publication Date
ES2933261T3 true ES2933261T3 (es) 2023-02-03

Family

ID=61224071

Family Applications (1)

Application Number Title Priority Date Filing Date
ES18827208T Active ES2933261T3 (es) 2017-12-01 2018-11-29 Procedimiento de enrutamiento de datos de una sesión inicializada entre un terminal y un servidor

Country Status (8)

Country Link
US (4) US11394787B2 (es)
EP (2) EP3732829B1 (es)
CN (4) CN111418186B (es)
ES (1) ES2933261T3 (es)
FR (1) FR3074626A1 (es)
PL (1) PL3732829T3 (es)
PT (1) PT3732829T (es)
WO (1) WO2019106308A1 (es)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3074626A1 (fr) * 2017-12-01 2019-06-07 Orange Procede d'acheminement de donnees d'une session initialisee entre un terminal et un serveur
CN114051750B (zh) * 2019-05-31 2024-04-09 苹果公司 用于性能数据流式传输、性能数据文件报告和性能阈值监测的系统和方法
WO2021019690A1 (ja) * 2019-07-30 2021-02-04 日本電信電話株式会社 スライスゲートウェイ、品質集計装置、検査パケット処理方法、及びプログラム
FR3101498A1 (fr) 2019-09-30 2021-04-02 Orange Procédé de contrôle d’un flux de données associé à un processus au sein d’un réseau mutualisé
FR3155398A1 (fr) * 2023-11-15 2025-05-16 Orange Procédé de contrôle d’une communication au cours de laquelle sont échangées des données relatives à un service, et dispositifs électroniques associés

Family Cites Families (59)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8266294B2 (en) * 2003-08-13 2012-09-11 Microsoft Corporation Routing hints
US9497132B2 (en) * 2013-04-23 2016-11-15 Telefonaktiebolaget Lm Ericsson (Publ) Method and system of implementing conversation-sensitive collection for a link aggregation group
US9985799B2 (en) * 2014-09-05 2018-05-29 Alcatel-Lucent Usa Inc. Collaborative software-defined networking (SDN) based virtual private network (VPN)
US10951519B2 (en) * 2015-06-17 2021-03-16 Oracle International Corporation Methods, systems, and computer readable media for multi-protocol stateful routing
EP3357267A1 (en) * 2015-09-29 2018-08-08 Telefonaktiebolaget LM Ericsson (PUBL) Securing network slice management
US10028168B2 (en) * 2015-12-08 2018-07-17 Huawei Technologies Co., Ltd. Method and apparatus for remote buffer status maintenance
US9961713B2 (en) * 2016-02-23 2018-05-01 Motorola Mobility Llc Procedures to support network slicing in a wireless communication system
FR3048574A1 (fr) * 2016-03-07 2017-09-08 Orange Selection d'une instanciation de tranche de reseau pour la transmission de paquets montants
US10609608B2 (en) * 2016-03-23 2020-03-31 Lg Electronics Inc. Method for changing connection mode in base station, and base station therefor, and method for changing connection mode in user equipment, and user equipment thereof
US20170289791A1 (en) * 2016-04-05 2017-10-05 Electronics And Telecommunications Research Institute Communication method and apparatus using network slice
US11089542B2 (en) * 2016-04-05 2021-08-10 Sharp Kabushiki Kaisha Terminal apparatus, base station apparatus, mobility management entity (MME), and communication control method
CN107277883A (zh) * 2016-04-08 2017-10-20 电信科学技术研究院 在多网络切片的网络中路由消息的方法、设备及系统
US10142994B2 (en) * 2016-04-18 2018-11-27 Electronics And Telecommunications Research Institute Communication method and apparatus using network slicing
US10028128B2 (en) * 2016-04-29 2018-07-17 Motorola Mobility Llc Procedures to support network slicing in a wireless communication system
US10986675B2 (en) * 2016-05-12 2021-04-20 Convida Wireless, Llc Connecting to virtualized mobile core networks
WO2017200978A1 (en) * 2016-05-16 2017-11-23 Idac Holdings, Inc. Security-based slice selection and assignment
US10362511B2 (en) * 2016-05-17 2019-07-23 Lg Electronics Inc. Method and apparatus for determining PDU session identity in wireless communication system
JP6692936B2 (ja) * 2016-06-15 2020-05-13 コンヴィーダ ワイヤレス， エルエルシー ネットワークスライス発見および選択
CN112165725B (zh) * 2016-06-15 2024-03-19 华为技术有限公司 报文处理的方法及设备
CN107852608B (zh) * 2016-07-04 2021-11-09 苹果公司 网络分片选择
US10757576B2 (en) * 2016-08-05 2020-08-25 Nxgen Partners Ip, Llc SDR-based massive MIMO with V-RAN cloud architecture and SDN-based network slicing
ES2899914T3 (es) * 2016-08-12 2022-03-15 Huawei Tech Co Ltd Selección de un segmento de red
JP6925411B2 (ja) * 2016-08-16 2021-08-25 アイディーエーシー ホールディングス インコーポレイテッド ネットワークスライス再選択
JP6671752B2 (ja) * 2016-08-22 2020-03-25 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． ネットワークスライス選択方法および装置
ES2945485T3 (es) * 2016-11-04 2023-07-03 Huawei Tech Co Ltd Método y terminal de cambio entre redes
CN106851589B (zh) * 2016-12-30 2019-02-19 北京小米移动软件有限公司 无线网络接入方法、装置及系统
CN108282352B (zh) * 2017-01-05 2021-03-23 华为技术有限公司 管理网络切片实例的方法、装置和系统
GB2558585A (en) * 2017-01-06 2018-07-18 Nec Corp Communication system
KR102549946B1 (ko) * 2017-01-09 2023-06-30 삼성전자주식회사 이동통신 환경에서 단말의 초기 접속 요청 메시지를 라우팅하는 방법 및 관련 파라미터
WO2018134483A1 (en) * 2017-01-23 2018-07-26 Nokia Technologies Oy Method and apparatus for complementary and equivalent network slice deployment in a network environment
US10531336B2 (en) * 2017-02-26 2020-01-07 Mariana Goldhamer Link control in centralized deployments
CN110214459B (zh) * 2017-03-01 2021-02-12 华为技术有限公司 业务处理的方法和设备
CN106982458B (zh) * 2017-03-09 2019-12-17 华为技术有限公司 一种网络切片的选择方法及装置
CN108632808B (zh) * 2017-03-17 2023-04-21 华为技术有限公司 核心网控制面设备选择方法和装置
EP3596969B1 (en) * 2017-03-24 2021-12-01 Huawei Technologies Co., Ltd. Slice-compliant handover control
US11178555B2 (en) * 2017-04-27 2021-11-16 Apple Inc. Enhanced network slice management for wireless communications
US10673751B2 (en) * 2017-04-27 2020-06-02 At&T Intellectual Property I, L.P. Method and apparatus for enhancing services in a software defined network
EP3616425B1 (en) * 2017-05-02 2021-10-27 Huawei Technologies Co., Ltd. Devices, systems and methods for accessing and providing network slices in a mobile communication network
US11122470B2 (en) * 2017-05-04 2021-09-14 Ofinno, Llc Network slice information for handover procedure
US10820185B2 (en) * 2017-05-08 2020-10-27 Qualcomm Incorporated Mobility between areas with heterogeneous network slices
US10382903B2 (en) * 2017-05-09 2019-08-13 At&T Intellectual Property I, L.P. Multi-slicing orchestration system and method for service and/or content delivery
FR3067197A1 (fr) * 2017-06-01 2018-12-07 Orange Procede de selection d'une tranche de reseau relative a une application
WO2018231125A1 (en) * 2017-06-16 2018-12-20 Telefonaktiebolaget Lm Ericsson (Publ) Network, network nodes, wireless communication devices and method therein for handling network slices in a wireless communication network
CN109151906B (zh) * 2017-06-16 2021-02-12 华为技术有限公司 通信方法、网络设备、终端设备和系统
CN110999431B (zh) * 2017-06-17 2022-04-05 Lg电子株式会社 用于在无线通信系统中注册终端的方法及其设备
EP3629614A4 (en) * 2017-06-29 2020-04-29 Huawei International Pte. Ltd. METHOD, DEVICE AND SYSTEM FOR ALLOCATING NETWORK WAFER
US11039321B2 (en) * 2017-07-05 2021-06-15 Huawei Technologies Co., Ltd. Methods and systems for network slicing
US10268474B2 (en) * 2017-07-18 2019-04-23 Cisco Technology, Inc. Network slice selection in a mobile network
CN109391648B (zh) * 2017-08-04 2020-12-22 华为技术有限公司 一种应用与网络切片的关联方法、装置和通信系统
CN109548098B (zh) * 2017-08-15 2023-10-24 华为技术有限公司 会话处理方法及相关设备
CN109429274B (zh) * 2017-09-04 2021-10-01 华为技术有限公司 一种配置方法以及对应装置
EP3688953B1 (en) * 2017-09-29 2022-12-21 Telefonaktiebolaget LM Ericsson (Publ) Creating a pseudonym for requesting a network slice
FR3072241A1 (fr) * 2017-10-05 2019-04-12 Orange Procede de mutation d'un terminal mobile entre stations d'acces dans un contexte multi-operateurs
CA3071180A1 (en) * 2017-10-16 2019-04-25 Ntt Docomo, Inc. Communication system, communication control device, and communication method
US11026128B2 (en) * 2017-10-19 2021-06-01 Qualcomm Incorporated Mechanism to enable interworking between network slicing and evolved packet core connectivity
CN112672383B (zh) * 2017-11-09 2023-02-10 华为技术有限公司 通信方法和网络设备
US10834668B2 (en) * 2017-11-14 2020-11-10 Ofinno, Llc AMF selection for isolated network slice
FR3074626A1 (fr) * 2017-12-01 2019-06-07 Orange Procede d'acheminement de donnees d'une session initialisee entre un terminal et un serveur
EP3836506A1 (en) * 2019-12-09 2021-06-16 Orange Providing cybersecurity services by a network and automated provisioning thereof

Also Published As

Publication number Publication date
US11394787B2 (en) 2022-07-19
CN111418186B (zh) 2023-06-09
EP3732829A1 (fr) 2020-11-04
EP3732829B1 (fr) 2022-09-14
US20200389527A1 (en) 2020-12-10
CN116684464A (zh) 2023-09-01
CN116684463B (zh) 2026-03-17
PT3732829T (pt) 2022-12-09
CN116684462A (zh) 2023-09-01
US12250276B2 (en) 2025-03-11
CN116684463A (zh) 2023-09-01
FR3074626A1 (fr) 2019-06-07
EP4132177C0 (fr) 2025-12-24
US20230403330A1 (en) 2023-12-14
WO2019106308A1 (fr) 2019-06-06
CN116684462B (zh) 2026-03-17
US20220311829A1 (en) 2022-09-29
US11785095B2 (en) 2023-10-10
US12143451B2 (en) 2024-11-12
PL3732829T3 (pl) 2023-01-09
CN111418186A (zh) 2020-07-14
US20230403329A1 (en) 2023-12-14
EP4132177A1 (fr) 2023-02-08
EP4132177B1 (fr) 2025-12-24

Similar Documents

Publication Publication Date Title
ES2933261T3 (es) Procedimiento de enrutamiento de datos de una sesión inicializada entre un terminal y un servidor
ES2927276T3 (es) Selección de un segmento de red relacionado con una aplicación
CN102577255B (zh) 云计算中企业的第2层无缝站点扩展
US20190007316A1 (en) Controller for software defined network
US11671483B2 (en) In-band protocol-based in-network computation offload framework
FR3067550A1 (fr) Procede de communication quic via des chemins multiples
TW201223206A (en) Multipath Transmission Control Protocol proxy
US20110075674A1 (en) Scalable architecture for enterprise extension in a cloud topology
US20060133390A1 (en) Method and apparatus providing prioritized convergence in border gateway protocol
ES3031040T3 (en) Method and device for obtaining an ip address
US9106257B1 (en) Checksumming encapsulated network packets
ES2878376T3 (es) Proceso de activación de tratamientos aplicados a una sesión de datos
US8711838B1 (en) Using network labels without standard-defined syntax and semantics
CN114448859B (zh) 支持用于边界网关协议的多传输选项
TW202249467A (zh) 5g網路中可選擇性的導入使用者設備位址至虛擬路由轉發表
US9686381B1 (en) Control word decapsulation in a hybrid BGP-VPLS network
CN115842876A (zh) 处理报文的方法、系统、设备和存储介质
US9917768B2 (en) System and method for reflecting FEC route information
TW202249466A (zh) 封包轉發控制協定（ｐｆｃｐ）會話負載平衡器運作系統及其運作方法
CN118449905A (zh) 流量路由方法和装置、存储介质及电子设备
Schulz et al. SCION-IP Translation in eBPF
US20260032741A1 (en) Using a user equipment with a telecommunications network, wherein the user equipment requests, while being connected to the telecommunications network, to be connected to or to access a further network
WO2024007640A1 (zh) 数据传输方法、数据处理方法、电子设备、存储介质
WO2025093520A1 (fr) Procédés et dispositifs pour la configuration et l'utilisation d'un réseau supportant des tranches réseau
Phung Enriching the internet control-plane for improved traffic engineering