ES2773126T3 - Transferencia en redes definidas por software - Google Patents
Transferencia en redes definidas por software Download PDFInfo
- Publication number
- ES2773126T3 ES2773126T3 ES13811444T ES13811444T ES2773126T3 ES 2773126 T3 ES2773126 T3 ES 2773126T3 ES 13811444 T ES13811444 T ES 13811444T ES 13811444 T ES13811444 T ES 13811444T ES 2773126 T3 ES2773126 T3 ES 2773126T3
- Authority
- ES
- Spain
- Prior art keywords
- entity
- plane
- parameter
- background
- foreground
- 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
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/0005—Control or signalling for completing the hand-off
- H04W36/0083—Determination of parameters used for hand-off, e.g. generation or modification of neighbour cell lists
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/10—Scheduling measurement reports ; Arrangements for measurement reports
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/0005—Control or signalling for completing the hand-off
- H04W36/0055—Transmission or use of information for re-establishing the radio link
- H04W36/0058—Transmission of hand-off measurement information, e.g. measurement reports
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/08—Reselecting an access point
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/20—Manipulation of established connections
- H04W76/27—Transitions between radio resource control [RRC] states
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Un método en una red definida por software, SDN, con separación de plano de usuario, que comprende: solicitar (S71), mediante una primera entidad en un primer plano, una primera entidad en un segundo plano para informar de un parámetro a la primera entidad en el primer plano, recibir (S72), en la primera entidad en el primer plano, el parámetro informado que se asigna a un protocolo de habilitación SDN, y reenviar (S73), mediante la primera entidad en el primer plano, el parámetro a una segunda entidad en el primer plano, caracterizado por que la primera entidad es una estación base de origen que inicia una transferencia y la segunda entidad es una estación base de destino a la cual se realiza la transferencia, el parámetro es un valor de recuento, y el primer plano es un plano de control/gestión y el segundo plano es un plano de usuario, que comprende además instruir, mediante la primera entidad en el primer plano, a la primera entidad en el segundo plano para redirigir los paquetes de datos provenientes de un terminal a una segunda entidad en el segundo plano; o instruir, mediante la primera entidad en el primer plano, a la primera entidad en el segundo plano para pasar de transmitir paquetes de datos directamente a un terminal a transmitir los paquetes de datos a través de la segunda entidad en el segundo plano.
Description
DESCRIPCIÓN
Transferencia en redes definidas por software
Campo de la invención
La presente invención se refiere a aparatos, métodos, programas informáticos, productos de programas informáticos y medios legibles por ordenador utilizables para la transferencia en redes definidas por software.
Antecedentes de la invención
La transmisión de datos móviles y los servicios de datos progresan constantemente, en el que dichos servicios proporcionan diversos servicios de comunicación, tal como voz, vídeo, datos de paquetes, mensajería, radiodifusión, etc. En años recientes, se ha especificado la evolución a largo plazo LTE™, que utiliza la red de acceso de radio terrestre universal evolucionada E-UTRAN como arquitectura de comunicación de radio de acuerdo con las especificaciones 3GPP.
Además, la virtualización de red se utiliza en tecnologías recientes, que divide las redes convencionales en subconjuntos para ser utilizados, operados y administrados por diferentes organizaciones organizacionalmente independientes. El uso de virtualización de red ofrece flexibilidad en el desarrollo de futuras arquitecturas de red. El campo técnico según la presente invención es la red definida por software (SDN, ver ONF en https://www.opennetworking.org/index.php7option=com_ content&view=category&layout=blog&id=41<emid=145&lang=en) para su uso, por ejemplo, en red de telecomunicaciones móviles. Dentro de la investigación de redes definidas por software SDN, se discute una separación del plano de control y el plano de usuario.
Es decir, en SDN, el sistema que toma decisiones sobre dónde se enviará el tráfico (plano de control) se desacopla de los sistemas subyacentes que envían el tráfico al destino seleccionado (plano de datos).
Hoy, el eNB es una entidad monolítica integrada que proporciona servicios al equipo de usuario 3GPP y media entre el Ue y el EPC (núcleo de paquetes evolucionado). Para proporcionar el servicio, el eNB en general soporta una parte de control y una parte de usuario. La parte de usuario del eNB (eNB-U, eNB en el plano de usuario) en general reenvía la carga útil hacia y desde el equipo de usuario hacia/desde el EPC. La parte de control del eNB (eNB-C, eNB en el plano de control) en general cubre la parte que permite el intercambio de la señalización de modo que el UE y el EPC puedan solicitar y otorgar servicios particulares. En caso de transferencia, están los eNB de origen y destino involucrados, donde el eNB de origen indica el eNB que dejará el UE, y donde el eNB de destino es el que recibe el UE.
En el plano de control vertical, se utiliza un protocolo de comunicación, tal como OpenFlow, FOrCES (protocolo de separación de elementos de reenvío y control), etc., para controlar las respectivas entidades.
En el caso de OpenFlow, por ejemplo, la llamada aplicación se monta en la parte superior del controlador OpenFlow (OFC, y se indica como OFC+ para indicar que el controlador está aumentado con una funcionalidad adicional). En especificaciones 3GPP, la movilidad de acceso Intra E-UTRAN y la transferencia basada en S1 (HO) se definen en TS 36.300 y TS 23.401. Sin embargo, actualmente, las especificaciones 3GPP no cubren una solución en un entorno SDN.
El documento "MobileFlow: Toward software-defined mobile networks", de KOSTAS PENTIKOUSIS ET AL, IEEE COMMUNICATIONS MAGAZINE, Julio 2013, describe el principio de SDN para red móvil. Este documento divulga una división de SGW y PGW en el plano de control y el plano de usuario, y que el eNB también podría dividirse en el plano C y U.
La figura 1 muestra un ejemplo de señalización en un caso de una transferencia intra E-UTRAN de equipo de usuario (UE) en el plano de control, como se muestra en Ts 36.300. A continuación se ofrece una breve explicación de las etapas que se muestran en la figura 1. Para más detalles al respecto, se hace referencia a la descripción en TS 36.300.
En la etapa 1, el eNB (Nodo B evolucionado) de origen configura los procedimientos de medición de UE de acuerdo con la información de restricción de acceso e itinerancia.
En la etapa 2, se activa un INFORME DE MEDICIÓN y se envía al eNB.
En la etapa 3, el eNB de origen toma una decisión basada en el INFORME DE MEDICIÓN y la información de gestión de recursos de radio (RRM) para transferir el UE.
En la etapa 4, el eNB de origen emite un mensaje de SOLICITUD DE ENTREGA al eNB de destino que pasa la información necesaria para preparar el HO en el objetivo.
En la etapa 5, el eNB de destino puede realizar un Control de Admisión.
En la etapa 6, el eNB de destino prepara HO con L1/l2 y envía el RECONOCIMIENTO DE SOLICITUD DE ENTREGA al eNB de origen.
En la etapa 7, la fuente eNB envía el mensaje RRC, es decir, el mensaje ReconfíguradónConexiónRRC, incluyendo la InformaciónControlmovilidad, hacia el UE.
En la etapa 8, el eNB de origen envía el mensaje TRANSFERENCIA DE ESTADO SN al eNB de destino para transmitir el estado del receptor PDCP SN (número de secuencia del protocolo de convergencia de datos de paquetes) y el estado del transmisor PDCP SN de enlace descendente de E-RAB (portadora de acceso de radio E-UTRAN) para el cual se aplica la preservación del estado de PDCP.
Después de la etapa 8, el reenvío de datos se realiza desde el eNB de origen hacia el eNB de destino.
En la etapa 9, después de recibir el mensaje ReconfiguraciónConexiónRRC, incluyendo la InformaciónControlmovilidad, el UE realiza la sincronización con el eNB de destino y accede a la célula objetivo a través de RACH (Canal de acceso aleatorio).
En la etapa 10, el eNB de destino responde con asignación UL y avance de tiempo.
En la etapa 11, cuando el UE ha accedido con éxito a la célula objetivo, el UE envía el mensaje ReconfiguraciónConexiónRRCCompleta (C-RNTI, Identidad temporal de la red de radio celular) para confirmar la transferencia, junto con un informe de estado de memoria intermedia de enlace ascendente, cuando sea posible, al eNB de destino para indicar que el procedimiento de transferencia se ha completado para el UE.
En la etapa 12, el eNB de destino envía un mensaje de SOLICITUD DE CAMBIO DE RUTA a MME (Entidad de gestión de movilidad) para informar que el UE ha cambiado de célula.
En la etapa 13, la MME envía un mensaje de SOLICITUD DE MODIFICACIÓN DE PORTADORA a la puerta de enlace de servicio (SGW).
En la etapa 14, la puerta de enlace de servicio cambia la ruta de datos del enlace descendente al lado de destino. La puerta de enlace de servicio envía uno o más paquetes de "marcador final" en la ruta anterior al eNB de origen y luego puede liberar cualquier recurso de plano U/t Nl (capa de red de transporte) hacia el eNB de origen.
En la etapa 15, la puerta de enlace de servicio envía un mensaje de MODIFICAR RESPUESTA DE LA PORTADORA a la MME.
En la etapa 16, la MME confirma el mensaje SOLICITUD DE CAMBIO DE RUTA con el mensaje RECONOCIMIENTO DE SOLICITUD DE CAMBIO DE RUTA.
En la etapa 17, enviando el mensaje de LIBERACIÓN DE CONTEXTO DE UE, el eNB de destino informa el éxito de HO al eNB de origen y desencadena la liberación de recursos por parte del eNB de origen. El eNB de destino envía este mensaje después de que el MME recibe el mensaje RECONOCIMIENTO DE SOLICITUD DE CAMBIO DE RUTA.
En la etapa 18, al recibir el mensaje de LIBERACIÓN DE CONTEXTO DE UE, el eNB de origen puede liberar recursos relacionados con la radio y el plano C asociados al contexto UE. Cualquier reenvío de datos en curso puede continuar.
De acuerdo con la figura 1, el eNB de origen reenvía los datos del plano de usuario y la transferencia de estado de SN al eNB de destino al menos después de recibir la confirmación de solicitud de transferencia (véanse las etapas 6 y 8 en la figura 1).
Además, de acuerdo con la figura 1, el eNB de destino reenvía los datos del plano de usuario al UE y a la SGW al menos después de recibir la transferencia de estado SN y el mensaje ReconfiguraciónConexiónRRCCompleta (véanse las etapas 8 y/o 9 a 11 de la figura 1).
Sin embargo, en el entorno SDN, el protocolo Open-Flow y/o el protocolo Forces no son capaces de soportar estas características en la actualidad.
Es decir, con respecto al eNB de origen, en el entorno SDN/OPENFLOW/Forces, el controlador eNB de origen (o cualquier otro controlador RAN (red de acceso de radio)) actualmente no puede enviar el valor de RECUENTO DL y el valor de RECUENTO UL disponible en el eNB-U del eNB de origen al eNB-C de destino.
Además, con respecto al eNB de destino, en el entorno SDN/OPENFLOW/Forces, el controlador eNB de destino (o cualquier otro controlador RAN) actualmente no puede enviar el valor RECUENTO DL y el valor RECUENTO UL disponible en el eNB-C al eNB-U de destino.
El recuento de DL y UL es necesario en el eNB-U de destino para la correcta sincronización de los paquetes.
Además, se observa que de acuerdo con las especificaciones actuales de OpenFlow (OF), solo hay tres mensajes que se pueden enviar al controlador OF (es decir, entrada de paquete, Flujo eliminado, Estado del puerto) pero que, por definición, no satisfacen las necesidades de transferencia.
Para facilitar la comprensión de la presente descripción, se indica lo siguiente:
- Los paquetes IP desde el eNB hacia el UE se envían a través del protocolo PDCP, y los paquetes IP del eNB hacia el EPC (núcleo de paquete evolucionado) se envían a través del protocolo g TP-U (plano de usuario de protocolo de tunelado GPRs );
- El número de PDCP PDU (unidad de paquete de datos) que se transporta a través de GTP-U (transferencia del SN) se define en el capítulo 5.2.2.2 del t S 29281;
- El Sn PDCP para el protocolo PDCP se define en el capítulo 6.2.4 de TS 36323;
- El valor RECUENTO (UL y DL) transportado a través de la transferencia de estado SN en la interfaz X2 se define en el capítulo 9.1.1.4 y el capítulo 9.2.15 de TS 36423.
- El valor RECUENTO (UL y Dl ) transportado a través de la transferencia de estado MME/eNB en la interfaz S1 se define en TS 36413.
Sumario de la invención
Por lo tanto, es un objeto de la presente invención superar los problemas mencionados anteriormente y proporcionar aparatos, métodos, programas informáticos, productos de programas informáticos y medios legibles por ordenador utilizables para la transferencia en redes definidas por software, por ejemplo, transferencia X2 y/o S1-MME en eNB de origen y eNB de destino.
De acuerdo con un aspecto de la presente invención, se proporciona un método como se define en la reivindicación 1.
De acuerdo con otro aspecto de la presente invención, se proporciona un método como se define en la reivindicación 3.
De acuerdo con todavía otro aspecto de la presente invención, se proporciona un aparato como se define en la reivindicación 11. De acuerdo con todavía otro aspecto de la presente invención, se proporciona un aparato como se define en la reivindicación 12.
De acuerdo con otro aspecto de la presente invención, se proporciona un producto de programa informático que comprende medios de código adaptados para producir etapas de cualquiera de los métodos descritos anteriormente cuando se cargan en la memoria de un ordenador.
De acuerdo con todavía otro aspecto de la invención, se proporciona un producto de programa informático como se define anteriormente, en el que el producto de programa informático comprende un medio legible por ordenador en el cual se almacenan las porciones de código de software.
De acuerdo con todavía otro aspecto de la invención, se proporciona un producto de programa informático como se define anteriormente, en el que el programa se puede cargar directamente en una memoria interna del dispositivo de procesamiento.
Aspectos y características adicionales de acuerdo con versiones de ejemplo de la presente invención se exponen en las reivindicaciones dependientes.
Breve descripción de los dibujos
Estos y otros objetos, características, detalles y ventajas se harán más evidentes a partir de la siguiente descripción detallada de aspectos/realizaciones de la presente invención, que debe tomarse junto con los dibujos adjuntos, en los que:
La figura 1 es un diagrama de señalización que ilustra un ejemplo de señalización en un caso de una
transferencia intra E-UTRAN de equipo de usuario en el plano de control;
La figura 2 es un diagrama que ilustra un escenario de ejemplo al que se aplican ciertas realizaciones de la presente invención;
La figura 3 es un diagrama que ilustra un ejemplo del flujo de paquetes en el enlace descendente antes de la transferencia;
La figura 4 es un diagrama que ilustra un ejemplo del flujo de paquetes en el enlace ascendente antes de la transferencia;
La figura 5 es un diagrama que ilustra un ejemplo de un flujo de paquetes en enlace ascendente durante la transferencia de acuerdo con ciertas realizaciones de la presente invención;
La figura 6 es un diagrama que ilustra un ejemplo del flujo de paquetes en enlace descendente durante la transferencia de acuerdo con ciertas realizaciones de la presente invención;
La figura 7 es un diagrama de flujo que ilustra un ejemplo de un método de acuerdo con un versiones de ejemplo de la presente invención;
La figura 8 es un diagrama de flujo que ilustra otro ejemplo de un método de acuerdo con versiones de ejemplo de la presente invención;
La figura 9 es un diagrama que ilustra un ejemplo de un aparato de acuerdo con versiones de ejemplo de la presente invención;
La figura 10 es un diagrama de flujo que ilustra otro ejemplo de un método de acuerdo con versiones de ejemplo de la presente invención;
La figura 11 es un diagrama de flujo que ilustra otro ejemplo de un método de acuerdo con versiones de ejemplo de la presente invención;
La figura 12 es un diagrama que ilustra otro ejemplo de un aparato de acuerdo con versiones de ejemplo de la presente invención.
Descripción de realizaciones de ejemplo
Se describirán a continuación aspectos de ejemplo de la presente invención. De manera más específica, aspectos a modo de ejemplo de la presente invención se describen a continuación con referencia a ejemplos particulares no limitantes y a lo que actualmente se consideran realizaciones concebibles de la presente invención. Un experto en la materia apreciará que la invención no se limita en modo alguno a estos ejemplos, y puede aplicarse de manera más amplia.
Debe observarse que la siguiente descripción de la presente invención y sus realizaciones se refieren principalmente a especificaciones que se usan como ejemplos no limitantes para ciertas configuraciones e implementaciones de red a modo de ejemplo. Específicamente, la presente invención y sus realizaciones se describen principalmente en relación con las especificaciones 3GPP que se utilizan como ejemplos no limitantes para ciertas configuraciones e implementaciones de red a modo de ejemplo. Como tal, La descripción de las realizaciones a modo de ejemplo dadas en el presente documento se refiere específicamente a la terminología que está directamente relacionada con las mismas. Dicha terminología solo se usa en el contexto de los ejemplos no limitativos presentados, y naturalmente no limita la invención de ninguna manera. En su lugar, cualquier otra configuración de red o despliegue del sistema, etc. también se puede utilizar siempre que cumpla con las características descritas en este documento.
En adelante, se describen diversas realizaciones e implementaciones de la presente invención y sus aspectos o realizaciones usando varias alternativas. En general se observa que, de acuerdo con ciertas necesidades y limitaciones, todas las alternativas descritas pueden proporcionarse solas o en cualquier combinación concebible (incluyendo también combinaciones de características individuales de las diversas alternativas).
Como ya se indicó anteriormente, la presente invención generalmente se refiere a SDN de red definida por software para su uso, por ejemplo, en redes de telecomunicaciones móviles.
Las realizaciones de la presente invención abordan el problema de cómo realizar una transferencia de eNB en un entorno SDN/OpenFlow. A continuación, se discutirán tanto el eNB de origen como el eNB de destino.
La figura 2 muestra un escenario de ejemplo al que son aplicables las realizaciones de la presente invención.
Por supuesto, debe observarse que las realizaciones de la presente invención no se limitan al escenario de ejemplo ilustrado y que cualquier otro número adecuado de UE, eNB, AP (puntos de acceso), estaciones base y cualquier conexión adecuada entre las mismas son concebibles.
De acuerdo con la figura 2, se proporcionan un eNB-C de origen 61 del plano de control y un eNB-U de origen 63 del plano de usuario. Además, se proporcionan el eNB-C de destino 64 del plano de control y un eNB-U de destino 66 del plano de usuario. Entre los respectivos eNB-C 61 y 64 y los respectivos eNB-U 63 y 66, se proporcionan los respectivos controladores OpenFlow OFC+ 62 y 65 con funcionalidad adicional. El eNB-C de origen 61 y el eNB-C de destino 64 están conectados a través de una interfaz X2-C. El eNB-U de origen 63 y el eNB-U de destino 66 están conectados a través de una interfaz X2-U. Además, se proporciona un equipo de usuario UE 67 que está conectado a los eNB-U 63 y 66 a través de las respectivas interfaces LTE-Uu. Además, el UE puede estar conectado a los eNB-C 61 y 64 del plano de control a través de una interfaz LTE-Uu RRC, que no se muestra en la figura 2. eNB de origen
En primer lugar, el comportamiento en el eNB de origen se explicará de acuerdo con ciertas realizaciones de la presente invención.
Para superar el problema anteriormente mencionado, de acuerdo con ciertas realizaciones de la presente invención, se sugiere que al menos los denominados valores Recuento UL y Recuento DL, tal como se definen en el "Contenedor transparente de transferencia de estado eNB" incluido en "TRANSFERENCIA DE ESTADO eNB" y/o "TRANSFERENCIA DE ESTADO MME" (ver, por ejemplo, el capítulo 9.2.1.31 de 3GPP TS 36.413) son solicitados primero por el eNB-C/OFC+ y se mapean en un protocolo de habilitación SDN, tal como, por ejemplo, OpenFlow o Forces, de modo que el plano de usuario separado del eNB de origen pueda informar los valores de recuento UL y DL a la aplicación del plano de control de eNB de origen una vez que el reenvío de datos al eNB de destino haya comenzado o esté a punto de comenzar.
En general, lo mismo se aplica al mensaje basado en X2 llamado "Transferencia de estado SN" enviado desde el eNB de origen al eNB de destino (como se define en TS 36423).
Con la recepción del ACK de solicitud de transferencia, como se muestra en la figura 2, en el eNB-C, el eNB-C instruye al enB-U a través del OFC+ con el mensaje OpenFlow Mod_Flow para cambiar/redirigir los paquetes UL y DL destinados/originados a/desde el UE para enviarlos al eNB de destino.
Además, el eNB-C solicita al eNB-U que informe de los valores de recuento UL/DL al eNB-C cuando el estado del transmisor/receptor está congelado, es decir, cuando se detuvo (o cuando se detendrá) asignando SN de PDCP a paquetes SDU (Unidad de Datos de Servicio) para DL y se detuvo (o se detendrá) la entrega de paquetes UL hacia el EPC.
Una vez que se recibe el informe correspondiente del valor de recuento UL/DL (ya sea a través de un mensaje artificial de "entrada de paquete" OpenFlow activado en particular por la redirección de estos paquetes individuales (y los siguientes paquetes) o un nuevo mensaje propietario de OpenFlow que informa los valores de recuento) en el eNB-C, los valores de recuento se insertan en el mensaje de transferencia de estado X2 SN y se envían al eNB-C de destino.
El caso de uso importante es el soporte de la transferencia intra E-UTRAN, pero la misma solución también se puede aplicar a la transferencia basada en S1 también.
Los mismos principios en general se pueden aplicar a cualquier otro elemento RAN, como los ya conocidos en el pasado, por ejemplo, BTS, etc. y/o similares, así como los del futuro como LTE-A y 5G, etc.
Alternativamente, de acuerdo con ciertas realizaciones de la presente invención, la fuente eNB-C puede solicitar enviar todos los paquetes o solo el primer paquete desde el plano de usuario hasta el plano de control a través de un mensaje artificial de "entrada de paquete". En tal caso, el controlador OpenFlow puede redirigir los paquetes manipulados hacia el nuevo destino por sí mismos.
Se admite que esto puede requerir que se modifique el protocolo Open-Flow para que el PDCP pueda coincidir. Sin embargo, dicha solución alternativa tendría un impacto en el canal de control OpenFlow y el controlador OpenFLow y el plano de control.
A continuación, se describirán ciertas realizaciones de la presente invención en detalle con referencia a las figuras 3 a 6.
La figura 3 ilustra un ejemplo del flujo de paquetes en el enlace descendente en el plano del usuario antes de la transferencia.
Como se muestra en la figura 3, antes de la transferencia, el eNB de origen reenvía los paquetes PDCP solo al UE a través de la interfaz LTE-Uu.
La figura 4 ilustra un ejemplo del flujo de paquetes en el enlace ascendente en el plano de usuario antes de la transferencia.
Como se muestra en la figura 4, antes de la transferencia, el eNB de origen reenvía los paquetes GTP solo a la SGW.
Con (o al menos después de) la recepción del ACK de solicitud de transferencia en el eNB de origen, la transferencia se inicia en el eNB de origen, como se ha mencionado anteriormente.
La figura 5 muestra un ejemplo del flujo de paquetes en el enlace ascendente durante la transferencia.
[ENLACE ASCENDENTE]
Como se muestra en la figura 2 descrita anteriormente, el eNB-C de origen del plano de control instruye a la fuente eNB-U del plano de usuario a través de OFC+ para que cambie de enviar los paquetes GTP-U directamente al SGW a enviar los paquetes GTP-U al eNB de destino, como se ilustra en la figura 5, insertando el nuevo indicador "Cambio de enlace ascendente al eNB de destino" en el mensaje de Openflow "AñadirFlujo" o "Mod-Flujo".
Esto requiere que el S eNB-U realice lo siguiente:
a) comience a enviar los paquetes GTP-U de enlace ascendente durante un cierto período de tiempo simultáneamente al eNB de destino y al SGW directamente a través de la interfaz S1-U, mientras asigna e inserta los SN de PDCP en la extensión GTP-U "Número PDCP PDU" al eNB de destino,
b) luego (después de un intervalo de tiempo t) deje de enviar paquetes de enlace ascendente directamente hacia el SGW, y simultáneamente, deje de asignar e insertar los SN de PDCP en la extensión GTP-U "Número PDCP PDU" al eNB de destino, y
c) informe/notifique, por ejemplo, a través de un mensaje artificial OpenFlow "entrada de paquete" (pero sin asignar una memoria intermedia y una ID de memoria intermedia en el conmutador) a la OFC/eNB-C el primer número SN que no se envió a través de la interfaz S1-U y que no se insertó en los SN de PDCP en la extensión GTP-U "Número PDCP PDU".
Por lo tanto, en este caso, la fuente eNB-U informa el número SN a la OFC/eNB-C. La OFC/eNB-C a su vez inserta esto en la "Transferencia de estado SN" o "TRANSFERENCIA DE ESTADO DE eNB", que se envía al eNB-C de destino (posiblemente a través de MME).
La figura 6 ilustra un ejemplo del flujo de paquetes en el enlace descendente durante la transferencia.
[ENLACE DESCENDENTE]
El eNB-C de origen ordena al eNB-U de origen a través de OFC+ que cambie de enviar los paquetes PDCP directamente al UE a enviar los paquetes PDCP a través del eNB de destino, como se muestra en la figura 6, insertando la nueva marca "Cambiar enlace hacia abajo al eNB de objetivo" en el mensaje de Openflow "AñadirFlujo" o "ModFlujo".
Esto requiere que el S eNB-U realice lo siguiente:
a) comience a enviar los paquetes PDCP durante un cierto período de tiempo simultáneamente al eNB de destino y al UE directamente a través de la interfaz LTE-Ue, mientras asigna e inserta los PDCP SN en la extensión GTP-U "Número PDCP PDU",
b) Luego, deje de enviar paquetes de enlace directamente hacia el UE y, simultáneamente, deje de asignar e insertar los SN de PDCP en el "Número de PDU PDCP" de la extensión gTp-U, y
c) informe/notifique, por ejemplo, a través de un mensaje artificial OpenFlow "entrada de paquete" (pero sin asignar una memoria intermedia y una ID de memoria intermedia en el conmutador) a la OFC/eNB-C el primer número SN que no se envió a través de la interfaz LTE-Uu y que no se insertó en los SN de PDCP en la extensión GTP-U "Número PDCP PDU".
Por lo tanto, en este caso, la fuente eNB-U informa el número SN a la OFC/eNB-C. La OFC/eNB-C a su vez inserta esto en la "Transferencia de estado SN" o "TRANSFERENCIA DE ESTADO DE eNB", que se envía al eNB de destino (posiblemente a través de MME).
De acuerdo con ciertas realizaciones de la presente invención, se proponen las siguientes nuevas acciones y coincidencias de OpenFlow en el S-eNB.
Como una nueva acción, se propone empujar PDCP PDU con SN a GTP-U (con longitud y contenido) en el eNB-U de origen (para UL y DL)
Como un nuevo campo de coincidencia, se propone informar/notificar SN al controlador mediante, por ejemplo, un "entrada de paquete" OpenFlow artificial (pero sin asignar una memoria intermedia y una ID de memoria intermedia en el conmutador), en caso de que el PDCP se redirija adicionalmente, por ejemplo, el eNB-U de origen informa al controlador eNB-C/OpenFlow el SN desde el cual los paquetes ya no se envían al UE o al SGW, pero al eNB de destino.
Alternativamente, como un nuevo campo de coincidencia, hay una propuesta de información/notificación de SN al controlador en todos los siguientes paquetes.
Es decir, como ya se mencionó anteriormente, la fuente eNB-C puede solicitar enviar todos los paquetes o solo el primer paquete desde el plano de usuario hasta el plano de control a través de un mensaje artificial de "entrada de paquete".
Específicamente, el S eNB-C necesita tener una noción sobre el número de secuencia y esto puede lograrse mediante un informe explícito de solo ese número de secuencia (por ejemplo, el parámetro) en cuestión o mediante un mensaje artificial entrada de paquete que lleva el número de secuencia como parte del paquete completo a la OFC+/eNB-C. El S eNB-C puede buscar en el "mensaje de entrada de paquete" solo el número de secuencia, puede extraerlo y enviarlo a través de GTP-C al T eNB-C, mientras que el resto del mensaje de entrada del paquete puede descartarse en el S-eNB-C.
Por lo tanto, en particular, como tal, no es necesario que el controlador redirija cualquier paquete manipulado hacia un nuevo destino.
Sin embargo, como el controlador ya recibió (el primero o) todos los paquetes y el controlador ya está involucrado en el procedimiento, podría usar el mensaje "salida de paquete" (que le indica al plano del usuario que envíe el paquete en el mensaje "salida de paquete" o los paquetes que han sido almacenados en la memoria intermedia) para reenviar la carga útil al T eNB-U.
En este sentido, se observa que el mensaje "Entrada de paquete" es un mensaje dentro de OpenFlow que normalmente informa la recepción de un paquete (desconocido) para el cual el plan de usuario no tiene una regla/instrucción sobre cómo actuar en este paquete (carga útil). En ese caso particular, el plano de usuario envía el paquete completo (desconocido) (o incluso más) al controlador y además almacena temporalmente este paquete y cualquier paquete posterior, y espera instrucciones adicionales del controlador, como por ejemplo enviar los paquetes almacenados en la memoria intermedia a destino particular a través de un puerto de salida o para descartarlos, o lo que sea que requiera el controlador.
En lo anterior, se han descrito ciertas realizaciones de la presente invención en detalle con respecto a un protocolo OpenFlow. A continuación, se hace una descripción más general de ciertas realizaciones de la presente invención con respecto a las figuras 7 a 9.
La figura 7 es un diagrama de flujo que ilustra un ejemplo de un método de acuerdo con un versiones de ejemplo de la presente invención.
De acuerdo con versiones de ejemplo de la presente invención, el método puede implementarse en una primera entidad en un primer plano y comprende solicitar, en la etapa S71, mediante una primera entidad en un primer plano, una primera entidad en un segundo plano para informar de un parámetro a la primera entidad en el primer plano, recibir, en la primera entidad en el primer plano, el parámetro informado en la etapa S72 y reenviar, mediante la primera entidad en el primer plano, el parámetro a una segunda entidad en el primer plano en la etapa S73.
De acuerdo con versiones de ejemplo de la presente invención, el método comprende además solicitar que todos los paquetes se envíen a un controlador ubicado entre la primera entidad en el primer plano y la primera entidad en el segundo plano.
De acuerdo con versiones de ejemplo de la presente invención, el método comprende, además, instruir, mediante la primera entidad en el primer plano, la primera entidad en el segundo plano para redirigir los paquetes de datos provenientes de un terminal a una segunda entidad en el segundo plano.
De acuerdo con versiones de ejemplo de la presente invención, el método comprende, además, instruir, mediante la primera entidad en el primer plano, la primera entidad en el segundo plano para pasar de transmitir paquetes de datos directamente a un terminal a transmitir los paquetes de datos a través de la segunda entidad en el segundo plano.
La figura 8 es un diagrama de flujo que ilustra otro ejemplo de un método de acuerdo con versiones de ejemplo de la
presente invención.
De acuerdo con versiones de ejemplo de la presente invención, el método puede implementarse en una primera entidad en un segundo plano y comprende recibir, en una primera entidad en un segundo plano, una solicitud para informar un parámetro en una etapa S81, y reenviar el parámetro a una primera entidad en un primer plano en una etapa S82.
De acuerdo con versiones de ejemplo de la presente invención, el método comprende, además, recibir, en la primera entidad en el segundo plano, una instrucción para redirigir paquetes de datos desde un terminal a una segunda entidad en un segundo plano, y transmitir paquetes de enlace ascendente simultáneamente hacia un elemento de red y la segunda entidad en el segundo plano durante un período de tiempo predeterminado, y asignar un parámetro a los paquetes de datos transmitidos a la segunda entidad en el segundo plano.
De acuerdo con versiones de ejemplo de la presente invención, el método comprende además detener la transmisión de paquetes de datos de enlace ascendente al elemento de red después de que haya transcurrido un cierto período de tiempo predeterminado, y detener la asignación del parámetro a los paquetes de datos transmitidos a la segunda entidad en el segundo plano.
De acuerdo con versiones de ejemplo de la presente invención, el método comprende, además, informar, mediante la primera entidad en el segundo plano, a la primera entidad en el primer plano, el primer parámetro que no se ha transmitido al elemento de red y que no se ha insertado en el paquete de datos transmitido a la segunda entidad en el segundo plano.
De acuerdo con versiones de ejemplo de la presente invención, el método comprende, además, transmitir, mediante la primera entidad en el segundo plano, todos los paquetes a un controlador ubicado entre la primera entidad en el primer plano y la primera entidad en el segundo plano.
De acuerdo con versiones de ejemplo de la presente invención, el método comprende, además, recibir, en la primera entidad en el segundo plano, una instrucción de la primera entidad en el primer plano, para pasar de transmitir paquetes de datos directamente a un terminal a transmitir los paquetes de datos a través de una segunda entidad en el segundo plano, transmitir paquetes de datos de enlace descendente simultáneamente hacia la segunda entidad en el segundo plano y el terminal durante un período de tiempo predeterminado, y asignar un parámetro a los paquetes de datos transmitidos a la segunda entidad en el segundo plano.
De acuerdo con versiones de ejemplo de la presente invención, el método comprende además detener la transmisión de paquetes de datos de enlace descendente al terminal después de que haya transcurrido un cierto período de tiempo, y detener la asignación del parámetro a los paquetes de datos transmitidos a la segunda entidad en el segundo plano.
De acuerdo con versiones de ejemplo de la presente invención, el método comprende, además, informar, mediante la primera entidad en el segundo plano, a la primera entidad en el primer plano, el primer parámetro que no se ha transmitido al terminal y que no se ha insertado en el paquete de datos transmitido a la segunda entidad en el segundo plano.
La figura 9 es un diagrama de bloque que muestra un ejemplo de un aparato de acuerdo con versiones de ejemplo de la presente invención.
En la figura 9, se muestra un diagrama de circuito de bloques que ilustra una configuración de un aparato 90, que está configurado para implementar los aspectos descritos anteriormente de la invención. Debe observarse que el aparato 90 que se muestra en la figura 9 puede comprender varios elementos o funciones adicionales además de los descritos a continuación en el presente documento, que se omiten en este documento por simplicidad, ya que no son esenciales para comprender la invención. Además, el aparato también puede ser otro dispositivo que tenga una función similar, tal como un conjunto de chips, un chip, un módulo, etc., que también puede ser parte de un aparato o unirse como un elemento separado del aparato, o similar.
El aparato 90 puede comprender una función de procesamiento o procesador 91, tal como una CPU o similar, que ejecuta instrucciones dadas por programas o similares relacionados con el mecanismo de control de flujo. El procesador 91 puede comprender una o más porciones de procesamiento dedicadas a un procesamiento específico como se describe a continuación, o el procesamiento puede ejecutarse en un único procesador. Las porciones para ejecutar dicho procesamiento específico también se pueden proporcionar como elementos discretos o dentro de uno o más procesadores o porciones de procesamiento adicionales, como en un procesador físico como una CPU o en varias entidades físicas, por ejemplo. El signo de referencia 92 indica unidades de transceptor o de entrada/salida (E/S) (interfaces) conectadas al procesador 91. Las unidades de E/S 92 pueden usarse para comunicarse con uno o más elementos de red, entidades, terminales o similares. Las unidades de E/S 92 pueden ser una unidad combinada que comprende equipos de comunicación hacia varios elementos de red, o pueden comprender una estructura distribuida con una pluralidad de interfaces diferentes para diferentes elementos de red. El signo de referencia 93
indica una memoria utilizable, por ejemplo, para almacenar datos y programas para ser ejecutados por el procesador 91 y/o como almacenamiento de trabajo del procesador 91.
El procesador 91 está configurado para ejecutar el procesamiento relacionado con los aspectos descritos anteriormente. En particular, el aparato 90 puede implementarse o puede ser parte de una primera entidad en un primer plano y puede configurarse para realizar un método como se describe en conexión con la figura 7. Por lo tanto, el procesador 91 se configura para realizar la solicitud, mediante la primera entidad en el primer plano, una primera entidad en un segundo plano para informar de un parámetro a la primera entidad en el primer plano, recibir, en la primera entidad en el primer plano, el parámetro informado y reenviar, mediante la primera entidad en el primer plano, el parámetro a una segunda entidad en el primer plano.
De acuerdo con versiones de ejemplo de la presente invención, el aparato 90 puede implementarse o puede ser parte de una primera entidad en un segundo plano y puede configurarse para realizar un método como se describe en conexión con la figura 8. A continuación, el procesador 91 se configura para realizar recibir, en la primera entidad en el segundo plano, una solicitud para informar un parámetro y reenviar el parámetro a una primera entidad en un primer plano.
Por lo tanto, de acuerdo con versiones de ejemplo de la presente invención, se proporcionan dos aparatos 90, uno para la primera entidad en el primer plano y uno para la primera entidad en el segundo plano, y los aparatos tienen cada uno una estructura como se ilustra en la figura 9.
De acuerdo con versiones de ejemplo de la presente invención, la primera entidad en el primer plano y la segunda entidad en el primer plano se colocan en una entidad común que incluye la funcionalidad de la primera entidad en el primer plano y la funcionalidad de la segunda entidad en el primer plano.
De acuerdo con versiones de ejemplo de la presente invención, la primera entidad es una entidad fuente que inicia una transferencia y la segunda entidad es una entidad de destino a la que se realiza la transferencia.
De acuerdo con versiones de ejemplo de la presente invención, el parámetro es un valor de recuento.
De acuerdo con versiones de ejemplo de la presente invención, la entidad es una estación base.
De acuerdo con versiones de ejemplo de la presente invención, el primer plano es un plano de control/gestión y el segundo plano es un plano de usuario.
De acuerdo con versiones de ejemplo de la presente invención, el elemento de red es un elemento de red que tiene funcionalidad de puerta de enlace, y el terminal es un equipo de usuario, un servidor, aplicación o puerta de enlace. De acuerdo con versiones de ejemplo de la presente invención, los paquetes de datos al equipo de usuario se transmiten de acuerdo con un protocolo de convergencia de datos de paquetes y los paquetes de datos a la puerta de enlace o estación base se transmiten de acuerdo con un protocolo de túnel de datos de usuario GTP.
eNB de destino
Ahora, el comportamiento en el eNB de destino se explicará de acuerdo con ciertas realizaciones de la presente invención.
En general, en el lado eNB de destino, se sugiere que el eNB-C de destino envíe el valor de recuento de DL y UL al eNB-U. El eNB-U debe almacenarlos y debe usar los valores en la portadora de DL y UL.
Al recibir el mensaje de transferencia de estado X2 SN, como se muestra en la figura 2, el eNB-C 64 de destino recupera los valores de recuento UL/DL y los envía con el mensaje de flujo abierto "Mod-Flujo" en nuevos parámetros propietarios hacia el eNB-U 66 a través de OFC+ 65.
Al recibir el mensaje OpenFlow "Mod-Flujo" con los nuevos parámetros patentados (valor de recuento UL/DL con el correspondiente PDCP SN) en el eNB-U de destino 66, El eNB-U 66 almacena los valores correspondientes.
En el caso de enlace descendente, para cada portadora para la que se recibe el valor RECUENTO DE DL en el mensaje de OpenFlow "Flujo_Mod", el eNB-U de destino 66 lo usará para marcar, con el valor contenido en el nuevo parámetro propietario, el primer paquete de enlace descendente para el que aún no hay un SN PDCP asignado (en el GTP-U). Para cualquier paquete siguiente, PDCP SN se incrementa.
En el caso de enlace ascendente, para cada portadora para la que se recibe el valor RECUENTO DE UL en el mensaje de OpenFlow "Flujo_Mod", el eNB-U 66 objetivo no entregará ningún paquete de enlace ascendente (a la SGW) que tenga un SN PDCP menor que el valor contenido en el IE PDCP-SN del recuento UL.
El caso de uso importante es el soporte de la transferencia intra E-UTRAN, pero la misma solución también se puede aplicar a la transferencia basada en S1 también.
Los mismos principios en general se pueden aplicar a cualquier otro elemento RAN, como los ya conocidos en el pasado, por ejemplo, BTS, etc. y/o similares, así como los del futuro como LTE-A y 5G, etc.
Alternativamente, tanto para el caso del enlace ascendente como del enlace descendente en el eNB-C de destino 64, el eNB-U 66 puede reenviar a pedido (desde el T eNB-C) cualquier paquete al eNB-C 64 a través del OFC+ 65, que podría inspeccionar el valor de recuento y puede reenviar el paquete sin modificar de nuevo al eNB-U 66 a través del "paquete" de OpenFlow (hacia el destino respectivo), o descartar el paquete.
Sin embargo, dicha solución alternativa tendría un impacto en el canal de control OpenFlow y el controlador OpenFlow y el plano de control.
A continuación, se describirán ciertas realizaciones de la presente invención en detalle con referencia a las figuras 3 a 6.
El flujo de paquetes en el enlace descendente y el enlace ascendente en el plano del usuario antes de la transferencia es el mismo que ya se describió anteriormente con respecto a la fuente eNB. Por lo tanto, se hace referencia a este respecto a las figuras 3 y 4 y la descripción respectiva de los mismos.
Como se muestra en la figura 3, en el caso de enlace descendente, antes de la transferencia, el eNB de origen reenvía los paquetes PDCP solo al UE a través de la interfaz LTE-Uu.
Como se muestra en la figura 4, en el caso de enlace ascendente, antes de la transferencia, el eNB de origen reenvía los paquetes GTP solo a la SGW.
Con la recepción de la transferencia de estado SN o transferencia de estado MME, la transferencia se inicia en el eNB-C de destino.
La figura 5 muestra un ejemplo del flujo de paquetes en el enlace ascendente durante la transferencia.
En cuanto al eNB-C/OFC+ de destino, al recibir el mensaje "Transferencia de estado SN" o "TRANSFERENCIA DE ESTADO MME", el eNB-C/OFC+ de destino informa/notifica el número SN al eNB-U de destino en el mensaje OpenFlow "AñadirFlujo" o "Modflujo". A continuación, en el eNB-U de destino, se requiere un nuevo procedimiento de comparación de OpenFlow y una nueva acción.
El nuevo campo de coincidencia con la nueva 'Capacidad de comparación' es capaz de comparar el contenido de los SN PDCP en la extensión GTP-U "Número PDCP PDU" con el número SN recibido a través de OpenFlow.
Si el número GTP-U es igual o mayor que el número SN recibido a través de OpenFlow, los paquetes se envían a la SGW. De lo contrario, los paquetes no se envían hacia la SGW.
Como un nuevo campo de coincidencia, se propone informar/notificar al controlador los siguientes paquetes, de modo que el controlador pueda descartar los paquetes por sí solo o reenviarlos al destino respectivo con, por ejemplo, un mensaje de salida de paquete.
Según las especificaciones actuales, las acciones Open-Flow solo se activan en caso de una coincidencia simple, es decir, si el número GTP-U coincide con el número SN.
Por lo tanto, se propone un nuevo procedimiento de coincidencia/nuevas reglas de comparación, y el nuevo procedimiento de comparación es capaz de comparar el número GTP-U y el número SN y revelar si el número GTP-U es menor o mayor que el número Sn , o revelar si el número GTP-U es igual o menor que el número SN, o igual o mayor que el número SN.
Además, se proponen algunas nuevas acciones basadas en el resultado de las nuevas reglas de comparación descritas anteriormente, a saber, ignorar o actuar/enviar.
Por ejemplo, como se ha descrito anteriormente, si el número GTP-U es igual o mayor que el número SN recibido a través de OpenFlow, los paquetes se envían a la SGW. De lo contrario, si el número GTP-U es menor que el número SN recibido a través de OpenFlow, los paquetes se ignoran, es decir, no se envían hacia la SGW.
La figura 5 ilustra el caso del enlace ascendente donde el eNB de destino reenvía el PDU PDCP desde GTP-U (con longitud y contenido) hacia la SGW.
La figura 6 muestra un ejemplo del flujo de paquetes en el enlace descendente durante la transferencia.
En cuanto al eNB-U de destino, al recibir el mensaje "Transferencia de estado SN" o "TRANSFERENCIA DE ESTADO MME", el eNB-C/OFC+ de destino informa/notifica el número SN al eNB-U de destino en el mensaje OpenFlow "AñadirFlujo" o "Modflujo". A continuación, en el eNB-U de destino, se requiere un nuevo procedimiento de comparación de OpenFlow y una nueva acción.
El nuevo campo de coincidencia con la nueva 'Capacidad de comparación' es capaz de comparar el contenido de los SN PDCP en la extensión GTP-U "Número PDCP PDU" con el número SN recibido a través de OpenFlow.
Si el número GTP-U es igual o mayor que el número SN recibido a través de OpenFlow, los paquetes se envían a la UE. De lo contrario, los paquetes no se envían hacia la UE.
Según las especificaciones actuales, como se ha descrito anteriormente, las acciones de OpenFlow solo se activan en caso de una coincidencia simple, es decir, si el número GTP-U coincide con el número SN.
Por lo tanto, se propone un nuevo procedimiento de coincidencia/nuevas reglas de comparación, y el nuevo procedimiento de comparación es capaz de comparar el número GTP-U y el número SN y revelar si el número GTP-U es menor o mayor que el número SN, o revelar si el número GTP-U es igual o menor que el número SN, o igual o mayor que el número SN.
Además, se proponen algunas nuevas acciones basadas en el resultado de las nuevas reglas de comparación descritas anteriormente, a saber, ignorar y actuar/enviar.
Por ejemplo, como se ha descrito anteriormente, el eNB-U de destino ignora los paquetes PDCP con un número SN inferior al número SN recibido a través de OpenFlow, basado en las reglas de comparación anteriores.
Además, el eNB-U objetivo envía paquetes PDCP con un número SN no inferior al número SN recibido a través de OpenFlow (e incrementa el número SN con cada paquete PDCP) al UE, basado en las reglas de comparación anteriores.
Por lo tanto, de acuerdo con ciertas realizaciones de la presente invención, en enlace descendente, el eNB de destino empuja el PDU PDCP (desde GTP-U) para el paquete PDCP hacia el UE.
En lo anterior, se han descrito ciertas realizaciones de la presente invención en detalle con respecto a un protocolo OpenFlow. A continuación, se hace una descripción más general de ciertas realizaciones de la presente invención con respecto a las figuras 10 a 12.
La figura 10 es un diagrama de flujo que ilustra un ejemplo de un método de acuerdo con unas versiones de ejemplo de la presente invención.
De acuerdo con versiones de ejemplo de la presente invención, el método puede implementarse en una segunda entidad en un primer plano y comprende recibir, en una segunda entidad en un primer plano, un mensaje que incluye un parámetro en una etapa S101, recuperar el parámetro del mensaje recibido en una etapa S102, y reenviar el parámetro recuperado a una segunda entidad en un segundo plano en una etapa S103.
La figura 11 es un diagrama de flujo que ilustra otro ejemplo de un método de acuerdo con versiones de ejemplo de la presente invención.
De acuerdo con versiones de ejemplo de la presente invención, el método puede implementarse además en una segunda entidad en un segundo plano y comprende recibir, en una segunda entidad en un segundo plano, un mensaje que incluye un parámetro en una etapa S111 y que almacena el parámetro en una etapa S112.
De acuerdo con versiones de ejemplo de la presente invención, el método comprende, además, recibir, en la segunda entidad en el segundo plano, un paquete de datos al que se asigna un parámetro desde una primera entidad en el segundo plano, y que compara el parámetro almacenado con el parámetro asignado al paquete de datos recibido.
De acuerdo con versiones de ejemplo de la presente invención, el método comprende, además, si se determina que el parámetro asignado al paquete de datos es igual o mayor que el parámetro almacenado, reenviar el paquete de datos, al que se asigna el parámetro, a un elemento de red.
De acuerdo con versiones de ejemplo de la presente invención, el método comprende, además, si se determina que el parámetro asignado al paquete de datos es igual o mayor que el parámetro almacenado, reenviar el paquete de datos, al que se asigna el parámetro, al terminal.
De acuerdo con versiones de ejemplo de la presente invención, el método comprende, además, si se determina que
el parámetro asignado al paquete de datos es igual o menor que el parámetro almacenado, ignorando el paquete de datos, al que se asigna el parámetro.
De acuerdo con versiones de ejemplo de la presente invención, la primera entidad en el primer plano y la segunda entidad en el primer plano se colocan en una entidad común que incluye la funcionalidad de la primera entidad en el primer plano y la funcionalidad de la segunda entidad en el primer plano.
De acuerdo con versiones de ejemplo de la presente invención, la primera entidad es una entidad fuente que inicia una transferencia y la segunda entidad es una entidad de destino a la que se realiza la transferencia.
De acuerdo con versiones de ejemplo de la presente invención, la entidad es una estación base.
De acuerdo con versiones de ejemplo de la presente invención, el primer plano es un plano de control/gestión y el segundo plano es un plano de usuario.
De acuerdo con versiones de ejemplo de la presente invención, el elemento de red es un elemento de red que tiene una funcionalidad de puerta de enlace, y el terminal es un equipo de usuario, un servidor, aplicación o puerta de enlace.
De acuerdo con versiones de ejemplo de la presente invención, el parámetro es un valor de recuento.
De acuerdo con versiones de ejemplo de la presente invención, los paquetes de datos al equipo de usuario se transmiten de acuerdo con un protocolo de convergencia de datos de paquetes y los paquetes de datos a la puerta de enlace o estación base se transmiten de acuerdo con un protocolo de túnel de datos de usuario GTP.
La figura 12 es un diagrama de bloque que muestra un ejemplo de un aparato de acuerdo con versiones de ejemplo de la presente invención.
En la figura 12, se muestra un diagrama de circuito de bloques que ilustra una configuración de un aparato 120, que está configurado para implementar los aspectos descritos anteriormente de la invención. Debe observarse que el aparato 120 que se muestra en la figura 12 puede comprender varios elementos o funciones adicionales además de los descritos a continuación en el presente documento, que se omiten en este documento por simplicidad, ya que no son esenciales para comprender la invención. Además, el aparato también puede ser otro dispositivo que tenga una función similar, tal como un conjunto de chips, un chip, un módulo, etc., que también puede ser parte de un aparato o unirse como un elemento separado del aparato, o similar.
El aparato 120 puede comprender una función de procesamiento o procesador 121, tal como una CPU o similar, que ejecuta instrucciones dadas por programas o similares relacionados con el mecanismo de control de flujo. El procesador 121 puede comprender una o más porciones de procesamiento dedicadas a un procesamiento específico como se describe a continuación, o el procesamiento puede ejecutarse en un único procesador. Las porciones para ejecutar dicho procesamiento específico también se pueden proporcionar como elementos discretos o dentro de uno o más procesadores o porciones de procesamiento adicionales, como en un procesador físico como una CPU o en varias entidades físicas, por ejemplo. El signo de referencia 122 indica unidades de transceptor o de entrada/salida (E/S) (interfaces) conectadas al procesador 121. Las unidades de E/S 122 pueden usarse para comunicarse con uno o más elementos de red, entidades, terminales o similares. Las unidades de E/S 122 pueden ser una unidad combinada que comprende equipos de comunicación hacia varios elementos de red, o pueden comprender una estructura distribuida con una pluralidad de interfaces diferentes para diferentes elementos de red. El signo de referencia 123 indica una memoria utilizable, por ejemplo, para almacenar datos y programas para ser ejecutados por el procesador 121 y/o como almacenamiento de trabajo del procesador 121.
El procesador 121 está configurado para ejecutar el procesamiento relacionado con los aspectos descritos anteriormente. En particular, el aparato 120 puede implementarse o puede ser parte de una segunda entidad en un primer plano y puede configurarse para realizar un método como se describe en conexión con la figura 10. Por lo tanto, el procesador 121 se configura para realizar recibir, en la segunda entidad en el primer plano, un mensaje que incluye un parámetro, recuperar el parámetro del mensaje recibido y reenviar el parámetro recuperado a una segunda entidad en un segundo plano.
De acuerdo con versiones de ejemplo de la presente invención, el aparato 120 puede implementarse o puede ser parte de una segunda entidad en un segundo plano y puede configurarse para realizar un método como se describe en conexión con la figura 11. Por lo tanto, el procesador 121 se configura además para realizar recibir, en la segunda entidad en el segundo plano, un mensaje que incluye un parámetro y almacenar el parámetro.
Por lo tanto, de acuerdo con versiones de ejemplo de la presente invención, se proporcionan dos aparatos 120, uno para la segunda entidad en el primer plano y uno para la segunda entidad en el segundo plano, y los aparatos tienen cada uno una estructura como se ilustra en la figura 12.
De acuerdo con versiones de ejemplo de la presente invención, la primera entidad en el primer plano y la segunda entidad en el primer plano se colocan en una entidad común que incluye la funcionalidad de la primera entidad en el primer plano y la funcionalidad de la segunda entidad en el primer plano.
De acuerdo con versiones de ejemplo de la presente invención, la primera entidad es una entidad fuente que inicia una transferencia y la segunda entidad es una entidad de destino a la que se realiza la transferencia.
De acuerdo con versiones de ejemplo de la presente invención, el parámetro es un valor de recuento.
De acuerdo con versiones de ejemplo de la presente invención, la entidad es una estación base.
De acuerdo con versiones de ejemplo de la presente invención, el primer plano es un plano de control/gestión y el segundo plano es un plano de usuario.
De acuerdo con versiones de ejemplo de la presente invención, el elemento de red es un elemento de red que tiene una funcionalidad de puerta de enlace, y el terminal es un equipo de usuario, un servidor, aplicación o puerta de enlace.
De acuerdo con versiones de ejemplo de la presente invención, los paquetes de datos al equipo de usuario se transmiten de acuerdo con un protocolo de convergencia de datos de paquetes y los paquetes de datos a la puerta de enlace o estación base se transmiten de acuerdo con un protocolo de túnel de datos de usuario GTP.
En lo anterior, se han descrito ciertas realizaciones de la presente invención con referencia a OpenFlow. Sin embargo, se observa que OpenFlow es solo un ejemplo y que la presente invención no se limita a OpenFlow y que ciertas realizaciones de la presente invención podrían aplicarse a cualquier otro protocolo de comunicación adecuado, como, por ejemplo, Forces, SNMP, NFV, NetConf, o similares.
Además, se observa que la presente invención también es aplicable a redes desarrolladas adicionalmente, como, por ejemplo, 5G. En tal caso, se introduce el llamado GW HeNB, que es una nueva función que comprende inherentemente funciones de eNB y MME y SGW simultáneamente.
Además, se observa que el control de origen y de destino del HeNB (eNB doméstico) (como por supuesto también el eNB normal) pueden centralizarse, ya que probablemente sería beneficioso especialmente en entornos de células pequeñas, donde se puede proporcionar un OFC centralizado (controlador OpenFlow), posiblemente ubicado en una función o conectado a, que se llama GW HeNB (Puerta de enlace de eNB doméstico) en 3GPP. Entonces, el GW HeNB se puede montar encima de un OFC+ centralizado, que controla los planos de usuarios de HeNB de origen y/o de destino responsables de (y puede ser, también adicionalmente el plano de usuario local).
Como una posibilidad adicional, no solo el eNB, sino también el HeNB y GW HeNB (Puerta de enlace de eNB doméstico) (ver TS36300 "Acceso de radio terrestre universal evolucionado (E-UTRA) y Red de acceso de radio terrestre universal evolucionado (E-UTRAN); Descripción general) y el HNB (ver TS 25467 "Arquitectura UTRAN para Nodo B doméstico 3G (HNB)") pueden aprovechar la invención. De manera similar al eNB normal, el HeNB/HNB se puede separar y controlar mediante OpenFlow/SDN/OFC+. Esto evitaría que las células pequeñas existentes, como Nokia Solutions y Networks Flexi Lite BTS, implementen toda la pila 3GPP (plano de control) como (Plano de Control X2 y la pila de planos de control GTP-C), ya que simplemente el plano de usuario solo se puede implementar cuando es apropiado.
En particular, las células pequeñas HeNB en general se comportan como el eNB ya descrito a este respecto, pero incluso la GW HeNB como mediador que actúa como el EPC (MME/SGW) hacia el HeNB y que actúa simultáneamente como un eNB hacia el EPC (MME/EPC) puede, por ejemplo, aplicar la invención basándose en los principios SDN. También, por ejemplo, el GW HeNB central puede indicarle a la parte del usuario de HeNB o eNB de origen y/o de destino que informe el número de secuencia/recuento o que los compare con el número de secuencia recibido a través del GTP-U (en lugar de confiar en el X2 interfaz "transferencia SN"). Además, dependiendo de las capacidades (que se pueden indicar o configurar en el GW HeNB) del HeNB, el plano de control Gw HeNB puede decidir mapearlo desde OpenFlow a X2 o S1 y viceversa.
Las determinadas realizaciones descritas anteriormente de la presente invención son particularmente ventajosas porque no cargan al controlador con requisitos adicionales de tráfico y cálculo. Por lo tanto, la presente invención de acuerdo con ciertas realizaciones puede implementarse fácilmente.
En la descripción a modo de ejemplo anterior de los aparatos, solo las unidades/medios que son relevantes para comprender los principios de la invención se han descrito utilizando bloques funcionales. Los aparatos pueden comprender unidades/medios adicionales que son necesarios para su operación respectiva como elemento de red, como estación base, y similares, respectivamente. Sin embargo, se omite una descripción de estas unidades/medios en esta memoria descriptiva. La disposición de los bloques funcionales de los aparatos no se interpreta para limitar la invención, y las funciones pueden realizarse por un bloque o dividirse adicionalmente en subbloques.
Cuando en la siguiente descripción se indica que el aparato (o algún otro medio) está configurado para realizar alguna función, esto debe interpretarse como equivalente a una descripción que indique que un procesador (es decir, al menos uno) o los circuitos correspondientes, potencialmente en cooperación con el código del programa de ordenador almacenado en la memoria del aparato respectivo, está configurado para hacer que el aparato realice al menos la función así mencionada. También, dicha función debe interpretarse como implementable de manera equivalente mediante un circuito o medios específicamente configurados para realizar la función respectiva (es decir, la expresión "unidad configurada para" se interpreta como equivalente a una expresión tal como "medios para").
Para el propósito de la presente invención como se describe anteriormente en este documento, se debe observar que
- etapas del método que probablemente se implementen como porciones de código de software y se ejecuten utilizando un procesador en un aparato (como ejemplos de dispositivos, aparatos y/o módulos de los mismos, o como ejemplos de entidades que incluyen aparatos y/o módulos por lo tanto), son independientes del código de software y se pueden especificar utilizando cualquier lenguaje de programación desarrollado conocido o futuro, siempre que se mantenga la funcionalidad definida por las etapas del método;
- generalmente, cualquier etapa del método es adecuado para implementarse como software o hardware sin cambiar la idea de los aspectos/realizaciones y su modificación en términos de la funcionalidad implementada; - etapas del método y/o dispositivos, unidades o medios que puedan implementarse como componentes de hardware en los aparatos definidos anteriormente, o en cualquier módulo(s) de los mismos, (por ejemplo, los dispositivos que llevan a cabo las funciones de los aparatos de acuerdo con los aspectos/realizaciones descritas anteriormente) son independientes del hardware y pueden implementarse utilizando cualquier tecnología de hardware desarrollada conocida o futura o cualquier híbrido de estos, tales como MOS (semiconductor de óxido de metal), CMOS (MOS complementario), BiMOS (MOS bipolar), BiCMOS (CMOS bipolar), ECL (lógica acoplada del emisor), TTL (Transistor-Transistor Lógico), etc., utilizando, por ejemplo, componentes ASIC (IC específico de aplicación (circuito integrado)), Componentes de FPGA (matrices de puertas programables en campo), Componentes CPLD (Dispositivo lógico programable complejo) o componentes DSP (Procesador de señal digital);
- dispositivos, unidades o medios (por ejemplo, los aparatos definidos anteriormente, o cualquiera de sus respectivas unidades/medios) pueden implementarse como dispositivos individuales, unidades o medios, pero esto no excluye que se implementen de manera distribuida en todo el sistema, siempre y cuando la funcionalidad del dispositivo, unidad o medio se conserve;
- un aparato puede estar representado por un chip semiconductor, un conjunto de chips o un módulo (hardware) que comprende dicho chip o conjunto de chips; esto, sin embargo, no excluye la posibilidad de que una funcionalidad de un aparato o módulo, en lugar de ser implementado por hardware, se implemente como software en un módulo (software) tal como un programa informático o un producto de programa informático que comprende porciones de código de software ejecutable para ejecución/llevarse a cabo en un procesador;
- un dispositivo puede considerarse un aparato o un conjunto de más de un aparato, ya sea funcionalmente en cooperación entre sí o funcionalmente independientemente uno del otro pero en una misma carcasa del dispositivo, por ejemplo.
En general, debe observarse que los respectivos bloques funcionales o elementos de acuerdo con los aspectos descritos anteriormente pueden implementarse por cualquier medio conocido, ya sea en hardware y/o software, respectivamente, si solo está adaptado para realizar las funciones descritas de las partes respectivas. Las etapas del método mencionadas se pueden realizar en bloques funcionales individuales o mediante dispositivos individuales, o una o más de las etapas del método se pueden realizar en un solo bloque funcional o mediante un solo dispositivo.
En general, cualquier etapa del método es adecuada para implementarse como software o hardware sin cambiar la idea de la presente invención. Los dispositivos y medios pueden implementarse como dispositivos individuales, pero esto no excluye que se implementen de manera distribuida en todo el sistema, siempre y cuando se mantenga la funcionalidad del dispositivo. Tales principios y similares deben considerarse conocidos por una persona experta.
El software en el sentido de la presente descripción comprende código de software como tal que comprende medios o porciones de código o un programa de ordenador o un producto de programa de ordenador para realizar las funciones respectivas, así como software (o un programa de ordenador o un producto de programa de ordenador) incorporado en un medio tangible tal como un medio legible por ordenador (almacenamiento) que haya almacenado en él una estructura de datos respectiva o medios/porciones de código o incorporados en una señal o en un chip, potencialmente durante su procesamiento.
Lista de abreviaciones:
BTS Estación base de transceptor
CP Plano de control
C-RNTI RNTI celular
DL enlace descendente
eNB Nodo B evolucionado
eNB-U Plano de usuario eNB
eNB-C Plano de control eNB
EPC Núcleo de paquete evolucionado
E-UTRAN RAN terrestre universal evolucionado Forces: Reenvío y separación de elementos de control HO Transferencia
LTE-A LTE avanzado
OF OpenFlow
PDCP protocolo de convergencia de paquetes de datos
PDU unidad de datos de protocolo
RACH Canal de acceso aleatorio
RAN red de acceso de radio
RNTI Identificador temporal de red de radio
RRC Control de recursos de radio
SDU Unidad de datos de servicio
SDN redes definidas por software
S eNB eNB de origen
SGW Puerta de enlace de señalización
SN número de secuencia
T eNB eNB de destino
TNL Capa de red de transporte
UL Enlace ascendente
UP Plano de usuario
Claims (12)
1. Un método en una red definida por software, SDN, con separación de plano de usuario, que comprende: solicitar (S71), mediante una primera entidad en un primer plano, una primera entidad en un segundo plano para informar de un parámetro a la primera entidad en el primer plano,
recibir (S72), en la primera entidad en el primer plano, el parámetro informado que se asigna a un protocolo de habilitación SDN, y
reenviar (S73), mediante la primera entidad en el primer plano, el parámetro a una segunda entidad en el primer plano, caracterizado por que
la primera entidad es una estación base de origen que inicia una transferencia y la segunda entidad es una estación base de destino a la cual se realiza la transferencia,
el parámetro es un valor de recuento, y
el primer plano es un plano de control/gestión y el segundo plano es un plano de usuario, que comprende además
instruir, mediante la primera entidad en el primer plano,
a la primera entidad en el segundo plano para redirigir los paquetes de datos provenientes de un terminal a una segunda entidad en el segundo plano; o
instruir, mediante la primera entidad en el primer plano, a la primera entidad en el segundo plano para pasar de transmitir paquetes de datos directamente a un terminal a transmitir los paquetes de datos a través de la segunda entidad en el segundo plano.
2. El método, de acuerdo con la reivindicación 1, que comprende adicionalmente:
solicitar que todos los paquetes se envíen a un controlador ubicado entre la primera entidad en el primer plano y la primera entidad en el segundo plano.
3. Un método en una red definida por software, SDN, con separación de plano de usuario, que comprende: recibir (S81), en una primera entidad en un segundo plano desde una primera entidad en un primer plano, una solicitud para informar de un parámetro,
asignar el parámetro en un protocolo de habilitación SDN, y
reenviar (S82) el parámetro a la primera entidad en un primer plano, caracterizado por que la primera entidad es una estación base de origen que inicia una transferencia,
el parámetro es un valor de recuento, y
el primer plano es un plano de control/gestión y el segundo plano es un plano de usuario, recibir, en la primera entidad en el segundo plano, una instrucción para redirigir paquetes de datos desde un terminal a una segunda entidad en el segundo plano, siendo la segunda entidad una estación base objetivo a la que se realiza la transferencia, o
recibir, en la primera entidad en el segundo plano, una instrucción de la primera entidad en el primer plano, para cambiar desde transmitir paquetes de datos directamente a un terminal a transmitir los paquetes de datos a través de una segunda entidad en el segundo plano.
4. El método de acuerdo con la reivindicación 3, que comprende adicionalmente:
en el caso de recibir, en la primera entidad en el segundo plano, la instrucción para redirigir paquetes de datos desde el terminal a la segunda entidad en el segundo plano,
transmitir paquetes de enlace ascendente simultáneamente hacia un elemento de red y la segunda entidad en el segundo plano durante un período de tiempo predeterminado, y
asignar un parámetro a los paquetes de datos transmitidos a la segunda entidad en el segundo plano, en donde la segunda entidad es una entidad objetivo a la cual se realiza la transferencia; y opcionalmente además comprende:
detener la transmisión de paquetes de datos de enlace ascendente al elemento de red después de que haya transcurrido un período de tiempo predeterminado, y detener la asignación del parámetro a los paquetes de datos transmitidos a la segunda entidad en el segundo plano; y opcionalmente además comprende: informar, mediante la primera entidad en el segundo plano, a la primera entidad en el primer plano, del primer parámetro que no se ha transmitido al elemento de red y que no se ha insertado en el paquete de datos transmitido a la segunda entidad en el segundo plano; o
transmitir, mediante la primera entidad en el segundo plano, todos los paquetes a un controlador situado entre la primera entidad en el primer plano y la primera entidad en el segundo plano.
5. El método de acuerdo con la reivindicación 3, que comprende adicionalmente:
en el caso de recibir, en la primera entidad en el segundo plano, la instrucción de la primera entidad en el primer plano, pasar de transmitir paquetes de datos directamente al terminal a transmitir los paquetes de datos a través de la segunda entidad en el segundo plano,
transmitir simultáneamente paquetes de datos de enlace descendente hacia la segunda entidad en el segundo plano y el terminal durante un período de tiempo predeterminado, y
asignar un parámetro a los paquetes de datos transmitidos a la segunda entidad en el segundo plano; y opcionalmente además comprende:
detener la transmisión de paquetes de datos de enlace descendente al terminal después de que haya transcurrido un cierto período de tiempo, y dejar de asignar el parámetro a los paquetes de datos transmitidos a la segunda entidad en el segundo plano; y opcionalmente además comprende:
informar, mediante la primera entidad en el segundo plano, a la primera entidad en el primer plano, del primer parámetro que no se ha transmitido al terminal y que no se ha insertado en el paquete de datos transmitido a la segunda entidad en el segundo plano.
6. El método de acuerdo con una cualquiera de las reivindicaciones 1 a 5, en el que
la primera entidad en el primer plano y la segunda entidad en el primer plano se colocan en una entidad común que incluye la funcionalidad de la primera entidad en el primer plano y la funcionalidad de la segunda entidad en el primer plano.
7. El método de acuerdo con una cualquiera de las reivindicaciones 1 a 6, en el que
el elemento de red es un elemento de red que tiene una funcionalidad de puerta de enlace, y el terminal es un equipo de usuario, un servidor, una aplicación o una puerta de enlace.
8. El método de acuerdo con la reivindicación 7, en el que
los paquetes de datos al equipo de usuario se transmiten de acuerdo con un protocolo de convergencia de datos de paquetes y los paquetes de datos a la puerta de enlace o a la estación base se transmiten de acuerdo con un protocolo de túnel de datos de usuario GTP.
9. Un producto de programa informático que comprende instrucciones que, cuando se implementan en un aparato (90, 120), hacen que el aparato realice un método de acuerdo con una cualquiera de las reivindicaciones 1 a 8.
10. El producto de programa informático de acuerdo con la reivindicación 9, en el que el producto de programa informático comprende un medio legible por ordenador en el cual se almacenan las porciones de código de software; o
en el que el programa se puede cargar directamente en una memoria interna del aparato.
11. Un aparato para una estación base de origen en una red definida por software, SDN, con separación de plano de usuario, que comprende al menos un procesador,
y
al menos una memoria para almacenar instrucciones que debe ejecutar el procesador, en donde las instrucciones están configuradas para, cuando son ejecutadas por el al menos un procesador, hacer que el aparato al menos realice:
solicitar (S71), mediante una primera entidad en un primer plano, una primera entidad en un segundo plano para informar de un parámetro a la primera entidad en el primer plano,
recibir (S72), en la primera entidad en el primer plano, el parámetro informado que se asigna a un protocolo de habilitación SDN, y
reenviar (S73), mediante la primera entidad en el primer plano, el parámetro a una segunda entidad en el primer plano, caracterizado por que
la primera entidad es la estación base de origen que inicia una transferencia y la segunda entidad es una estación base de destino a la cual se realiza la transferencia,
el parámetro es un valor de recuento, y
el primer plano es un plano de control/gestión y el segundo plano es un plano de usuario, que comprende además
instruir, mediante la primera entidad en el primer plano, a la primera entidad en el segundo plano para redirigir los paquetes de datos provenientes de un terminal a una segunda entidad en el segundo plano; o
instruir, mediante la primera entidad en el primer plano, a la primera entidad en el segundo plano para pasar de transmitir paquetes de datos directamente a un terminal a transmitir los paquetes de datos a través de la segunda entidad en el segundo plano.
12. Un aparato para una estación base de origen en una red definida por software, SDN, con separación de plano de usuario, que comprende al menos un procesador,
y
al menos una memoria para almacenar instrucciones que debe ejecutar el procesador, en el que las instrucciones están configuradas para, cuando son ejecutadas por el al menos un procesador, hacer que el aparato al menos realice:
recibir (S81), en una primera entidad en un segundo plano desde una primera entidad en un primer plano, una solicitud para informar de un parámetro,
asignar el parámetro en un protocolo de habilitación SDN, y
reenviar (S82) el parámetro a la primera entidad en un primer plano, caracterizado por que la primera entidad es la estación base de origen que inicia una transferencia, el parámetro es un valor de recuento, y el primer plano es un plano de control/gestión y el segundo plano es un plano de usuario,
recibir, en la primera entidad en el segundo plano, una instrucción para redirigir paquetes de datos desde un terminal a una segunda entidad en el segundo plano, siendo la segunda entidad una estación base objetivo a la que se realiza la transferencia, o
recibir, en la primera entidad en el segundo plano, una instrucción de la primera entidad en el primer plano, para cambiar desde transmitir paquetes de datos directamente a un terminal a transmitir los paquetes de datos a través de una segunda entidad en el segundo plano.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/EP2013/076855 WO2015090363A1 (en) | 2013-12-17 | 2013-12-17 | Handover in software defined networking |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2773126T3 true ES2773126T3 (es) | 2020-07-09 |
Family
ID=49876588
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES13811444T Active ES2773126T3 (es) | 2013-12-17 | 2013-12-17 | Transferencia en redes definidas por software |
Country Status (6)
| Country | Link |
|---|---|
| US (2) | US10080168B2 (es) |
| EP (2) | EP3429269B1 (es) |
| KR (1) | KR101918554B1 (es) |
| CN (1) | CN105981434B (es) |
| ES (1) | ES2773126T3 (es) |
| WO (1) | WO2015090363A1 (es) |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102833802B (zh) * | 2012-08-15 | 2015-09-23 | 电信科学技术研究院 | 一种数据转发方法及设备 |
| KR101918554B1 (ko) | 2013-12-17 | 2018-11-15 | 노키아 솔루션스 앤드 네트웍스 게엠베하 운트 코. 카게 | 소프트웨어 정의 네트워킹에서의 핸드오버 |
| WO2015090455A1 (en) * | 2013-12-20 | 2015-06-25 | Nokia Solutions And Networks Oy | Sgc and pgc and sgu and pgu allocation procedure |
| CN104301955A (zh) * | 2014-09-02 | 2015-01-21 | 中兴通讯股份有限公司 | 一种用户设备切换基站的方法及基站、用户设备 |
| KR101608593B1 (ko) * | 2014-10-07 | 2016-04-01 | 숭실대학교산학협력단 | Sdn 기반 분산형 모바일 네트워크에서의 이동 단말의 이동성을 지원하는 방법 및 그 장치 |
| EP3272103A1 (en) | 2015-03-20 | 2018-01-24 | Nokia Solutions and Networks GmbH & Co. KG | Coexistence of software defined network, network function virtualization and legacy networks |
| WO2016163032A1 (ja) * | 2015-04-10 | 2016-10-13 | 富士通株式会社 | 無線通信システム、基地局、移動局および処理方法 |
| US10341239B2 (en) | 2015-05-21 | 2019-07-02 | Qualcomm Incorporated | Efficient policy enforcement for downlink traffic using network access tokens—control-plane approach |
| CN105245376B (zh) * | 2015-10-15 | 2018-11-30 | 成都电科致远网络科技有限公司 | 基于sdn的住宅小区网络控制系统 |
| KR102010250B1 (ko) * | 2017-03-15 | 2019-10-21 | 한국전자통신연구원 | Sdn 전송 망 기반 이동통신 네트워크 |
| WO2018191952A1 (zh) * | 2017-04-21 | 2018-10-25 | 华为技术有限公司 | 网络切换方法、装置与系统 |
| CN109150767A (zh) * | 2017-06-16 | 2019-01-04 | 华为技术有限公司 | 一种数据包发送方法、装置及设备 |
| US11006312B2 (en) * | 2018-04-06 | 2021-05-11 | Apple Inc. | PDCP packet-based DDDS frame transmission |
| US12127047B2 (en) * | 2018-04-12 | 2024-10-22 | Qualcomm Incorporated | Access stratum (AS) security for a centralized radio access network (C-RAN) |
| WO2020088770A1 (en) * | 2018-11-01 | 2020-05-07 | Nokia Solutions And Networks Gmbh & Co. Kg | Method and apparatus for handover |
| EP4021079A1 (en) * | 2018-11-02 | 2022-06-29 | Telefonaktiebolaget Lm Ericsson (Publ) | Handling service data application protocol (sdapp) end markers at handover |
| US12207318B2 (en) * | 2021-10-14 | 2025-01-21 | Verizon Patent And Licensing Inc. | Method and system for inter-operator mobility service |
Family Cites Families (29)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070254667A1 (en) * | 2006-04-28 | 2007-11-01 | Joanna Jokinen | Inter-MME handover in evolved communication systems |
| TW200746864A (en) * | 2006-05-01 | 2007-12-16 | Interdigital Tech Corp | Method and apparatus for facilitating lossless handover in 3GPP long term evolution systems |
| WO2008136115A1 (ja) * | 2007-04-26 | 2008-11-13 | Fujitsu Limited | 基地局、移動局、通信システム、送信方法及びリオーダリング方法 |
| CN101400156B (zh) * | 2007-09-29 | 2012-06-06 | 华为技术有限公司 | 基于s1切换的下行及上行数据包转发方法 |
| JP5104260B2 (ja) * | 2007-12-04 | 2012-12-19 | 富士通株式会社 | 移動通信システム |
| JP4465015B2 (ja) * | 2008-06-20 | 2010-05-19 | 株式会社エヌ・ティ・ティ・ドコモ | 移動通信方法 |
| EP2136501B1 (en) * | 2008-06-20 | 2019-12-04 | LG Electronics Inc. | Method of delivering a PDCP data unit to an upper layer |
| US8565150B2 (en) * | 2009-03-11 | 2013-10-22 | At&T Mobility Ii Llc | Architectural model for LTE (long term evolution) EPC (evolved packet core) deployment |
| JP5458775B2 (ja) | 2009-09-28 | 2014-04-02 | 株式会社村田製作所 | アクチュエータアレイ |
| CN105451295B (zh) * | 2009-10-02 | 2019-04-12 | 三菱电机株式会社 | 移动通信系统 |
| KR20110071363A (ko) * | 2009-12-21 | 2011-06-29 | 한국전자통신연구원 | 이동 통신 시스템의 핸드오버 처리 장치 |
| CN102934486B (zh) * | 2010-06-01 | 2016-06-29 | 日本电气株式会社 | 基站、移动通信系统以及基站的呼叫允许控制方法和呼叫允许控制程序 |
| EP2442610B1 (en) * | 2010-10-13 | 2017-12-06 | Alcatel Lucent | In-sequence delivery of upstream user traffic during handover |
| US9253700B2 (en) * | 2010-12-01 | 2016-02-02 | Nec Corporation | Radio base station, relay base station, mobile terminal, mobile communication system, and operation control method |
| CN102202284B (zh) * | 2011-04-29 | 2013-06-12 | 电信科学技术研究院 | 最小化路测测量配置参数下发方法、系统和设备 |
| CN102790965B (zh) * | 2011-05-18 | 2016-09-14 | 华为技术有限公司 | 切换方法、基站、用户设备和移动管理实体 |
| JP2013197895A (ja) * | 2012-03-19 | 2013-09-30 | Fujitsu Ltd | 無線通信システム、基地局及び中継局並びに通信方法 |
| JP5758351B2 (ja) * | 2012-06-22 | 2015-08-05 | 株式会社Nttドコモ | 無線通信システム |
| US9578557B2 (en) * | 2012-07-06 | 2017-02-21 | Telefonaktiebolaget Lm Ericsson (Publ) | Delayed handover signalling in a mobile network |
| WO2014017838A1 (ko) * | 2012-07-24 | 2014-01-30 | 한국전자통신연구원 | 핸드오버 방법 및 그 장치 |
| CN102833802B (zh) * | 2012-08-15 | 2015-09-23 | 电信科学技术研究院 | 一种数据转发方法及设备 |
| CN109769278A (zh) * | 2012-09-28 | 2019-05-17 | 三菱电机株式会社 | 移动通信系统 |
| CN103209121B (zh) * | 2013-03-15 | 2019-02-01 | 中兴通讯股份有限公司 | 基于开放流协议的控制面设备的发现处理方法及装置 |
| EP2982172B1 (en) * | 2013-04-05 | 2016-07-13 | Telefonaktiebolaget LM Ericsson (publ) | Handover request indicating split of a radio bearer between cells |
| US10021643B2 (en) | 2013-07-03 | 2018-07-10 | Nokia Solutions And Networks Gmbh & Co. Kg | User plane IDLE mode buffering within software defined network architecture |
| CN103391296B (zh) * | 2013-07-29 | 2016-08-24 | 北京华为数字技术有限公司 | 一种控制器、转发器及通道建立方法和系统 |
| JP6110565B2 (ja) * | 2013-11-01 | 2017-04-05 | エルジー エレクトロニクス インコーポレイティド | セル訪問履歴伝送方法及びその無線装備 |
| KR101918554B1 (ko) | 2013-12-17 | 2018-11-15 | 노키아 솔루션스 앤드 네트웍스 게엠베하 운트 코. 카게 | 소프트웨어 정의 네트워킹에서의 핸드오버 |
| US10075888B2 (en) * | 2014-09-25 | 2018-09-11 | Qualcomm Incorporated | Service-specific air-interface selection |
-
2013
- 2013-12-17 KR KR1020167019286A patent/KR101918554B1/ko active Active
- 2013-12-17 CN CN201380082055.5A patent/CN105981434B/zh active Active
- 2013-12-17 EP EP18187410.8A patent/EP3429269B1/en active Active
- 2013-12-17 ES ES13811444T patent/ES2773126T3/es active Active
- 2013-12-17 WO PCT/EP2013/076855 patent/WO2015090363A1/en not_active Ceased
- 2013-12-17 EP EP13811444.2A patent/EP3085150B1/en active Active
- 2013-12-17 US US15/106,111 patent/US10080168B2/en active Active
-
2018
- 2018-05-23 US US15/987,579 patent/US10779206B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| US10779206B2 (en) | 2020-09-15 |
| KR20160101075A (ko) | 2016-08-24 |
| CN105981434A (zh) | 2016-09-28 |
| EP3085150B1 (en) | 2020-01-22 |
| EP3085150A1 (en) | 2016-10-26 |
| US20160337914A1 (en) | 2016-11-17 |
| EP3429269A1 (en) | 2019-01-16 |
| KR101918554B1 (ko) | 2018-11-15 |
| CN105981434B (zh) | 2019-08-06 |
| US20180279190A1 (en) | 2018-09-27 |
| EP3429269B1 (en) | 2020-01-29 |
| WO2015090363A1 (en) | 2015-06-25 |
| US10080168B2 (en) | 2018-09-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2773126T3 (es) | Transferencia en redes definidas por software | |
| US11032740B2 (en) | Method for performing a re-establishment of a PDCP entity associated with UM RLC entity in wireless communication system and a device therefor | |
| ES2620110T3 (es) | Aparato de nodo y método para establecer portadoras auxiliares | |
| US9426700B2 (en) | Method and apparatus for performing handover procedure in wireless communication system including mobile relay node | |
| US11109291B2 (en) | Method for performing handover in wireless communication system and device for same | |
| US8811347B2 (en) | Method and apparatus for selecting MME in wireless communication system including mobile relay node | |
| US9131424B2 (en) | Method and apparatus for releasing user equipment context in wireless communication system | |
| US20200112885A1 (en) | Handover control method and apparatus | |
| US8228871B2 (en) | Wireless handover optimization | |
| CN102783212B (zh) | 在无线通信系统中执行切换流程的方法和装置 | |
| US12063543B2 (en) | Network nodes and methods supporting multiple connectivity | |
| WO2019132234A1 (en) | Method for switching a bandwidth part (bwp) for configured ul resources in wireless communication system and a device therefor | |
| JP2020532887A (ja) | ハンドオーバー方法、アクセスネットワーク装置と端末装置 | |
| CN117121559A (zh) | 发送和接收信号的方法、装置和通信系统 | |
| WO2019066427A1 (en) | METHOD FOR MANAGING LOSS-FREE DATA IN A UM RLC ENTITY IN A WIRELESS COMMUNICATION SYSTEM AND DEVICE THEREFOR | |
| CA3235117A1 (en) | Data transmission method and communication apparatus | |
| CN117678292A (zh) | 用于在小数据传输期间配置用户设备的设备及方法 | |
| US20200296636A1 (en) | Cell handover method and apparatus | |
| BR112019020398A2 (pt) | método de comunicação de retransmissão e aparelho e sistema de comunicações de retransmissão |