ES2984485T3 - Procedimiento de determinación de una configuración de relés entre un punto de acceso y los terminales en una arquitectura en red - Google Patents

Abstract

La invención se refiere a un método para determinar una configuración de relé entre un punto de acceso y terminales en una arquitectura de red que comprende una pluralidad de entidades que incluyen al menos un punto de acceso, al menos un relé, un controlador y terminales, una configuración de relé que determina las capas intercambiadas entre las entidades, comprendiendo el método: - la generación de tres gráficos de red distintos, siendo un gráfico de red un gráfico que asocia una magnitud física asociada a cada intercambio de datos entre dos entidades entre el punto de acceso, el relé y los terminales, y a varias capas/niveles de protocolo, y - la elección de la configuración de relé en función de los gráficos de red. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Procedimiento de determinación de una configuración de relés entre un punto de acceso y los terminales en una arquitectura en red

[0001] La presente invención se refiere a un procedimiento de determinación de una configuración de relés entre un punto de acceso y los terminales en una arquitectura en red.

[0002] En las aplicaciones civiles previstas para arquitecturas LTE avanzadas, surgen problemas para la retransmisión, suponiendo la estandarización únicamente intercambios en la zona de cobertura directamente desde una estación base al terminal.

[0003] Esto plantea un problema particular para las retransmisiones a los terminales no cubiertos por una estación base, que es tanto más difícil de resolver cuanto más amplia sea la cobertura, así como la forma en que se logra la cobertura repercute en la satisfacción de la calidad del servicio, el impacto depende del tipo de servicio considerado.

[0004] Se conocen modificaciones de la arquitectura de la red que implican modificar en profundidad determinadas entidades de la arquitectura, incluida las de la entidad MME.

[0005] Por lo tanto, existe la necesidad de un procedimiento que permita responder al problema de la retransmisión que sea más fácil de implementar.

[0006] Para ello, se propone un procedimiento de determinación según la reivindicación 1.

[0007] Según otras realizaciones, el procedimiento de determinación de una configuración de al menos un relé entre un punto de acceso y los terminales en una arquitectura en red comprende una o varias de las características de las reivindicaciones 2 a 5, tomadas de forma aislada o según todas las combinaciones técnicamente posibles.

[0008] Otras características y ventajas de la invención aparecerán con la lectura de la descripción que se ofrece a continuación de realizaciones de la invención, dada a modo de ejemplo únicamente y en referencia a los dibujos que son:

- la figura 1 es una representación esquemática de una arquitectura en red LTE según el estado de la técnica, - la figura 2 es una representación de las pilas de protocolos en el plano de control para la arquitectura de la figura 1, - la figura 3 es una representación de las pilas de protocolos en el plano de usuario para la arquitectura de la figura 1, - la figura 4 es una representación esquemática de un ejemplo de arquitectura en red,

- la figura 5 es una representación de las pilas de protocolos en el plano de control para una primera configuración de la arquitectura de la figura 4 en un primer ejemplo,

- la figura 6 es una representación de las pilas de protocolos en el plano de usuario para la primera configuración en un primer ejemplo,

- la figura 7 es una representación de las pilas de protocolos en el plano de control para una segunda configuración de la arquitectura de la figura 4 en un primer ejemplo,

- la figura 8 es una representación de las pilas de protocolos en el plano de usuario para la segunda configuración en un primer ejemplo,

- la figura 9 es una representación de las pilas de protocolos en el plano de control para una tercera configuración de la arquitectura de la figura 4 en un primer ejemplo,

- la figura 10 es una representación de las pilas de protocolos en el plano de usuario para la tercera configuración en un primer ejemplo,

- la figura 11 es una representación de las pilas de protocolos en el plano de control para una primera configuración de la arquitectura de la figura 10 en un segundo ejemplo,

- la figura 12 es una representación de las pilas de protocolos en el plano de usuario para la primera configuración en un segundo ejemplo,

- la figura 13 es una representación de las pilas de protocolos en el plano de control para una segunda configuración de la arquitectura de la figura 10 en un segundo ejemplo,

- la figura 14 es una representación de las pilas de protocolos en el plano de usuario para la segunda configuración en un segundo ejemplo,

- la figura 15 es una representación de las pilas de protocolos en el plano de control para una tercera configuración de la arquitectura de la figura 10 en un segundo ejemplo,

- la figura 16 es una representación de las pilas de protocolos en el plano de usuario para la tercera configuración en un segundo ejemplo,

- la figura 17 es un organigrama de un ejemplo de procedimiento de determinación de configuraciones,

- las figuras 18 a 23 son ejemplos de gráficos de redes,

- las figuras 24 a 30 son ejemplos de capas utilizadas durante la implantación del procedimiento de determinación, y - las figuras 31 y 32 son esquemas que ilustran un mecanismo de configuración de las capas, y

- la figura 33 es un organigrama de un ejemplo de procedimiento de determinación de configuraciones.

[0009]Para todos los acrónimos y conceptos utilizados en la siguiente descripción, se invita al lector a consultar la parte GLOSARIO.

[0010]La figura 1 representa una arquitectura de red LTE según el estado de la técnica.

[0011]Tal arquitectura es una arquitectura 4G convencional. Tal arquitectura ha sido objeto de la estandarización 3GPP.

[0012]La figura 1 es una vista de la arquitectura de red móvil inalámbrica convencional.

[0013]La arquitectura de red comprende una pluralidad de entidades que actúan en distintas zonas Z1, Z2, Z3. La primera zona Z1 es la zona de aplicación, la segunda zona Z2 es la red central, y la tercera zona Z3 es la zona de cobertura y en la que se realiza la comunicación mediante comunicaciones inalámbricas.

[0014]La arquitectura de red incluye una primera entidad 10, una segunda entidad 12, una tercera entidad 14, una cuarta entidad 16 y una quinta entidad 18.

[0015]La primera entidad 10 es un eNodoB.

[0016]A continuación, la primera entidad 10 se indica como entidad eNodoB.

[0017]La segunda entidad 12 incluye dos partes, una primera subentidad 12A y una segunda subentidad 12B.

[0018]La primera subentidad 12A de la segunda entidad 12 es un S-GW.

[0019]En lo sucesivo, la primera subentidad 12A de la segunda entidad 12 se denomina entidad S-GW.

[0020]La segunda subentidad 12B de la segunda entidad 12 es un P-GW.

[0021]En lo sucesivo, la segunda subentidad 12B de la segunda entidad 12 se denomina entidad P-GW.

[0022]La tercera entidad 14 es un servidor de aplicaciones.

[0023]La cuarta entidad 16 es un MME.

[0024]El término MME designa una entidad de control de la arquitectura de red LTE, pero los expertos en la técnica ven claramente que en el contexto de la presente invención puede ser adecuada para la implementación de la invención una entidad con cualquier otro nombre que tenga las mismas funciones de control de MME que se usan en el contexto de esta invención.

[0025]En lo sucesivo, la cuarta entidad 16 se denomina entidad MME.

[0026]La quinta entidad 18 es un terminal UE.

[0027]En lo sucesivo, la quinta entidad 18 se indica como terminal UE.

[0028]La arquitectura de red es adecuada para operar de varias formas. El enlace ascendente designa una comunicación desde el terminal UE a la entidad eNodoB, y el enlace descendente designa una comunicación desde la entidad eNodoB al terminal UE. El enlace ascendente se designa a menudo por el término inglés «uplink» mientras que el enlace descendente se denomina con el término inglés «downlink».

[0029]El funcionamiento de la arquitectura de la figura 1 se describe ahora con referencia a las figuras 1 a 3.

[0030]En la figura 1, las líneas discontinuas corresponden a la parte de señalización. Esto ilustra el funcionamiento del plano de control (también denominado «control plane»). Las líneas continuas en negrita corresponden a la comunicación de datos para los usos de los servicios que brinda la arquitectura de red. Esto ilustra el funcionamiento del plano de usuario. El plano de usuario es también denominado plano de datos o «user plane».

[0031]De hecho, para esta arquitectura clásica LTE, la normalización 3GPP ha definido un plano de control (o «Control Plane» en inglés) y un plano de usuario (o «User Plane» en inglés). El plano de control se muestra en la figura 2, y el plano de usuario se muestra en la figura 3.

[0032]Cabe señalar que la estandarización 3GPP también definió una distribución en capas de la misma manera que para el modelo OSI, siendo esta distribución en capas específica de la estandarización 3GPP. Esta división en capas o subcapas no se analiza en esta etapa con el fin de simplificar la descripción. Por otra parte, el término de «capa» se emplea sistemáticamente en lo sucesivo para designar una capa o una subcapa, de manera que la noción de «subcapa» y de «capa» depende del contexto. Se pueden encontrar más detalles relacionados con esta distribución en la sección GLOSARIO.

[0033] A continuación, se describe el funcionamiento de la arquitectura de enlace descendente. Usando la descripción del funcionamiento de la arquitectura de enlace descendente, un experto en la técnica puede derivar de manera similar el funcionamiento de la arquitectura de enlace ascendente.

[0034] En la figura 2, en la entidad MME, para el plano de control, los datos pasan a través de una capa NAS, una capa S1-AP, una capa SCTP, una capa IP, una capa L2 y una capa L1.

[0035] En la figura 2, en la entidad eNodoB, para el plano de control, los datos pasan a través de una capa L1, una capa L2, una capa IP, a continuación una capa SCTP, una capa S1-AP y después una capa RRC, una capa PDCP, una capa RLC, una capa MAC y una capa PhY.

[0036] En el terminal UE, los datos pasan a través de una capa PHY, una capa MAC, una capa RLC, una capa PDCP, una capa RRC y una capa NAS.

[0037] Durante el cruce de las capas, se realizan operaciones, correspondiendo estas operaciones al título de la capa atravesada. Las operaciones son, por ejemplo, modificaciones de los encabezados y la encapsulación/desencapsulación de cada dato.

[0038] En la figura 3, en la entidad P-GW, para el plano de usuario, los datos pasan a través de una capa IP, una capa GTP-U, una capa UDP/IP, una capa L2 y una capa L1.

[0039] En la entidad S-GW, los datos pasan a través de una capa L1, una capa L2, una capa UDP/IP, una capa GTP-U, a continuación una capa UDP/IP, una capa L2 y una capa L1.

[0040] En el eNodoB, para el plano de usuario, los datos pasan a través de una capa L1, una capa L2, una capa UDP/IP, una capa GTP-U, a continuación una capa PDCP, una capa RLC, una capa MAC y una capa PHY.

[0041] En el terminal UE, los datos pasan a través de una capa PHY, una capa MAC, una capa RLC, una capa PDCP, una capa IP y una capa de aplicación.

[0042] Cabe señalar que, en función del servicio, los paquetes también podrían ser generados por la capa de aplicación de otro terminal en la misma red, o también en otras redes si existen puertas de enlace.

[0043] Debe observarse, por ejemplo, que las funciones PDCP en el plano de usuario incluyen el cifrado y el descifrado, la compresión y descompresión RoHC del encabezado de los paquetes que provienen de las capas superiores (por ejemplo, desde IP) (también denominado «RoHC header compression»), la numeración de las secuencias (también denominada «sequence numbering») y la eliminación de los paquetes duplicados (también denominada «duplicate removal»).

[0044] Por el contrario, en el plano de control, las funciones PDCP incluyen el cifrado y descifrado, la protección de integridad, la numeración de secuencias, y la eliminación de paquetes duplicados.

[0045] Hay una instancia PDCP por «radio bearer». El «radio bearer» es similar a un canal lógico para encaminar los datos de usuario.

[0046] En la figura 4 se muestra un ejemplo de arquitectura de red. La arquitectura se aplica a todas las pilas de protocolos de las figuras 5 a 16.

[0047] Los elementos comunes con la arquitectura de red de la figura 1 no se detallan a continuación, aplicándose las mismas indicaciones. Solo las diferencias se describen a continuación.

[0048] Al contrario que en el caso de la figura 1, en la figura 4, la entidad eNodoB incluye dos partes: un emisor/receptor de radio 10A y una máquina virtual VM 10B. Más sencillamente, en lo sucesivo, el emisor/receptor de radio 10A se denomina entidad RRH (en las figuras de 11 a 16) o TP (en las figuras de 5 a 10) y la máquina virtual VM 10B se denota por VM. La entidad 10A puede ser un RRH o un TP, y la combinación 10A y VM 10B forma el equivalente de una estación base o eNodoB.

[0049] La entidad 10A es un punto de acceso simplificado, 10A puede ser, por ejemplo, un RRH o un TP.

[0050]El punto de acceso se simplifica en el sentido de que solo una parte de las capas son implementadas por la entidad r Rh o TP.

[0051]Más específicamente, la entidad TP implementa capas inferiores al nivel 3, preferentemente estrictamente inferiores a 3, y la entidad RRH implementa capas inferiores al nivel 2, preferentemente estrictamente inferiores a 2.

[0052]Así, según el ejemplo propuesto, la entidad 10A implementa de una manera completa al menos una de las capas siguientes: PHY, MAC, RLC y PDCP.

[0053]Según otra realización, la entidad 10A implementa capas de manera parcial, por ejemplo la capa PHY y una o varias subcapas de la capa L2 por ejemplo la subcapa MAC solamente o las subcapas MAC y RLC.

[0054]La VM es una máquina virtual.

[0055]La VM tiene la función de implementar una parte o todas las capas superiores. Por ejemplo, la VM es adecuada para transmitir capas superiores al nivel 2, preferentemente estrictamente superiores a 2.

[0056]A modo de ilustración, según un caso particular, la VM es capaz de transmitir total o parcialmente una o más capas de nivel 2 como la capa MAC, la capa RLC o la capa PDCP, y una o más capas de nivel 3 o superior como RRC o NAS.

[0057]La VM tiene, en algunos casos, la funcionalidad de una BBU (véase la definición en la parte GLOSARIO).

[0058]En la figura 4, la VM forma parte funcionalmente del RAN, pero la VM se ejecuta en máquinas (unidades de cálculo, u otra máquina con recursos de cálculo y de almacenamiento capaces de implementar la VM) que residen geográficamente lejos de la entidad de emisor/receptor de radio 10A (arquitectura de tipo «cloud», por nube).

[0059]Como alternativa, la VM se ejecuta en máquinas físicas (unidades de cálculo, u otra máquina con recursos de cálculo y de almacenamiento capaces de implementar la VM) que están geográficamente próximas o colocalizadas con la entidad de emisor/receptor de radio 10A o entonces se ejecuta en la entidad de emisor/receptor de radio 10A si la máquina física en la que se implementa la entidad de emisor/receptor de radio 10A tiene suficientes recursos de cálculo y de memoria (arquitectura de tipo «edge» o descentralizada, en la que los recursos están más bien en el borde de la red).

[0060]Al contrario que en el caso de la figura 1, en la figura 4, se conectan ahora terminales 18 e incluso una quinta entidad UE 18A y una sexta entidad UE 18B (normalmente fuera de cobertura de la red) a la red a través de otro terminal 20 con una función de relé.

[0061]La quinta entidad UE 18A se denomina terminal UE1 en lo sucesivo y la sexta entidad UE 18B se denomina terminal UE2.

[0062]Los dos terminales UE1 y UE2 forman parte de una cuarta zona Z4 que es una zona fuera de cobertura.

[0063]La arquitectura también incluye una séptima entidad UE-R 20.

[0064]El UE-R 20 es una entidad de relé indicada por el relé UER a continuación.

[0065]La arquitectura incluye además una octava entidad 22.

[0066]La octava entidad 22 es un controlador, denominado controlador CC a continuación.

[0067]En el ejemplo mostrado, el controlador CC es único.

[0068]La VM tiene una configuración controlada por el controlador CC.

[0069]Como alternativa, el controlador CC incluye dos partes: una parte que implementa funcionalidades para aplicaciones lentas y otra parte que implementa funcionalidades para aplicaciones en tiempo real.

[0070]Según el caso, las dos partes del controlador CC son dos entidades distintas o coubicadas.

[0071]En el diagrama de la figura 4, las líneas discontinuas en negrita corresponden a la parte de señalización. Esto ilustra el funcionamiento del plano de control (también denominado «control plane»). Las líneas continuas en negrita corresponden a la parte de uso. Esto ilustra el funcionamiento del plano de usuario. El plano de usuario es también denominado plano de datos o «user plane». La curva en líneas discontinuas representa una comunicación particular denominada «legacy communication» por «comunicación según el estándar o estado de la técnica ya disponible». Las líneas en trazo continuo no en negrita representan la comunicación del plano de control «legacy», es decir, implementado según el estado de la técnica actual.

[0072]El funcionamiento de la arquitectura de la figura 4 se describe ahora con referencia a múltiples configuraciones operativas posibles, ilustradas particularmente por las figuras 5 a 16.

[0073]En los esquemas de plano de usuario y de plano de control se adoptan las convenciones siguientes: X designa por ejemplo un protocolo de tipo SCTP; Y designa por ejemplo un protocolo de tipo UDP; L2t es un protocolo de tipo L2 utilizado entre la VM y la entidad TP (o RRH), por ejemplo L2 Ethernet; L1t es un protocolo de tipo L1 utilizado entre la VM y la entidad Tp (o RRH), por ejemplo L1 Ethernet; L0t es un protocolo de tipo CPRI, OBSAI o ORI utilizado entre la VM y la entidad RRH. En este caso, PHY I/Q se transmiten directamente en L0t. Estas convenciones se utilizan en particular en el texto. Para los ejemplos que se ofrecen a continuación en las figuras 5 a 10, se supone también que la entidad 10 A está provista de las funcionalidades PHY y MAC.

[0074]Además, si una capa se pone entre paréntesis, esto significa que el protocolo asociado es opcional, es decir, que se usa o no. Por ejemplo, una capa NAS con NAS entre paréntesis implica que el protocolo está implementado o no. Según otro ejemplo, una capa PDCP con PDCP entre paréntesis implica que el protocolo está implementado o no. Otro ejemplo se refiere a las capas X e Y, o X/IP e Y/IP.

[0075]Además, si un conjunto de capas está superpuesto, significa que puede tener varias capas que funcionan en paralelo, o que puede tener varias entidades distintas que pueden funcionar en paralelo (como por ejemplo varios MME 16 que están conectados al mismo CC 22, porque un UER 20 y/o porque uno o varios UE 18, 18A o 18B están conectados a MME diferentes - potencialmente son gestionados por MME diferentes).

[0076]Las figuras 5 y 6 ilustran una primera configuración denominada de «Single-Hop relaying». El término «Single-hop relaying» es una retransmisión de un terminal UE a través del relé UER, o una configuración a un salto. Para aclaración, el número de saltos se cuenta aquí a partir del relé UER.

[0077]En el ejemplo de la figura 5, para el plano de control, en la entidad MME, los datos pasan a través de una capa NAS, una capa S1-AP, una capa SCTP, una capa IP, una capa L2 y una primera capa L1.

[0078]En el controlador CC, los datos pasan a través de una capa L1, una capa L2, una capa IP, una capa SCTP, una capa S1-AP y una capa NAS y después una capa «Ctr. Layer» (capa para el plano de control), capa que es responsable de la transmisión del plano de control que pasa a través de CC hacia la VM, una capa SCTP/iP y una capa L2/L1. En lo relativo a la capa «Capa de control», puede utilizar un protocolo de tipo X2-AP o S1-AP que se utilizan normalmente en las interfaces X2-C o S1-C/S1-MME. Una función «Ctr. F.» (servidor) puede estar presente para controlar la configuración de la capa Capa de control entre el CC y la VM. A diferencia de «Capa de control» que es una capa, «Ctr. F.» es así una función responsable de la aplicación del protocolo que se utilizará para «Capa de control», y se trata así de una función de nivel superior.

[0079]En la VM, para el plano de control, los datos pasan a través de una capa L2/L1, una capa SCTP/IP, una capa Capa de control, y después una capa NAS, una capa RRC, una capa PDCP, una subcapa NAS R, una capa RRC R, una capa PDCP R (no forzosamente en este orden, como se ilustra más adelante en las figuras 24, 26, 28 y 29), una capa RLC R, las capas (X/IP) y L2t/L1t. Por ejemplo, en la VM, los datos con destino al UER pasan a través de capas L1 y L2, capas IP y SCTP, una capa Capa de control, y después una capa NAS R, una capa RRC R, una capa PDCP R, una capa RlC R, capas (X/IP) y L2t/L1t. Y en otro ejemplo, en la VM, los datos con destino al UE 18A (UE1) pasan a través de capas L1 y L2, capas IP y SCTP, una capa Capa de control, y después una capa NAS, una capa RRC, una capa PDCP, otra capa<p>D<c>P R, una capa RLC R, capas (X/IP) y L2t/L1t. La VM también puede presentar una función «Ctr. F.» (cliente) para la configuración de la capa Capa de control entre el CC y la VM («Ctr. F.» (cliente) en la VM es así una función similar «Ctr. F.» (servidor) que existe en CC).

[0080]En la entidad TP, los datos pasan a través de las capas L1t y L2t, una capa (X/IP), y después una capa MAC y una capa PHY.

[0081]En el relé UER, para el plano de control con destino al UER, los datos pasan a través de una capa PHY, una capa MAC, una capa RLC R, una capa PDCP R, una capa RRC R, una capa NAS R; y para el plano de control con destino al UE1, los datos pasan a través de una capa PHY, una capa MAC, una capa RLC R, una capa PDCP R a continuación una capa genérica L2, y después una capa genérica L1.

[0082]En el terminal UE1, los datos pasan a través de una capa genérica L1, una capa genérica L2, una capa PDCP, una capa RRC y una capa NAS.

[0083]En el ejemplo de la figura 6, en la entidad P-GW y en la entidad S-GW, los datos pasan como en las entidades P-GW y S-GW de la figura 3.

[0084] En la VM, en el plano de usuario, los datos pasan a través de una capa L1, una capa L2, una capa UDP/IP, una capa GTP-U, una capa PDCP, una capa PDCP R, una capa RLC R, las capas (Y/IP) y L2t/L1t. Esto se puede implementar de forma parcial. Más precisamente, en la VM, los datos con destino al UER pasan a través de una capa L1, una capa L2, una capa UDP/IP, una capa GTP-U, una capa PDCP R, una capa RLC R, capas (Y/IP) y L2t/L1t, y los datos con destino al Ue 18A (UE1) pasan a través de una capa L1, una capa L2, una capa UDP/IP, una capa GTP-U, una capa PDCP, una capa PDCP R, una capa RLC R, capas (Y/IP) y L2t/Llt.

[0085] En la entidad TP, en el plano de usuario, los datos pasan a través de las capas L1t, L2t, a continuación una capa (Y/IP), una capa MAC y una capa PHY.

[0086] En el relé UER, los datos que se dirigen al mismo relé UER pasan a través de una capa PHY, una capa MAC, una capa RLC R, una capa PDCP R, una capa IP, una capa de aplicación. En el relé UER, los datos que se dirigen a la entidad 18A (terminal UE1) bajo cobertura de radio del relé UER pasan a través de una capa PHY, una capa MAC, una capa RLC R, una capa PDCP R, y después una capa genérica L2 y una capa genérica L1.

[0087] En el terminal UE1, los datos pasan a través de una capa genérica L1, una capa genérica L2, una capa PDCP, una capa IP y una capa de aplicación.

[0088] En este caso, la capa PDCP UE está encapsulada en una capa PDCP UE-R. El relé UER retransmite la información al terminal UE1 sin decodificarla/desencriptarla o descifrarla.

[0089] Por otra parte, debe observarse que la entidad 18 A fuera de la zona está controlada por la VM con ayuda de las subcapas RRC o NAS (ver también figura 5).

[0090] Las figuras 7 y 8 ilustran una segunda configuración denominada de «Single-Hop relaying».

[0091] Se aplican los mismos elementos que para el plano de usuario y el plano de control de la primera configuración para el plano de usuario y el plano de control según la segunda configuración. En lo sucesivo solo se detallan las diferencias.

[0092] En el plano de control en la figura 7, en la VM, los datos pasan a través de capas diferentes entre la capa Capa de control y la capa (X/IP) que son la capa NAS, la capa RRC, la capa PDCP UE y la capa RLC R.

[0093] En el relé UER, las capas PDCP R, RRC R y NAS R no se cruzan ni se utilizan.

[0094] Finalmente, en el primer terminal UE, los datos pasan a través de una capa de PDCP UE. En el plano de usuario en la figura 8, en la VM, el cruce de los datos por las capas PDCP y PDCP R se reemplaza por el cruce de una única capa PDCP UE. El UER retransmite paquetes al UE sin cifrado adicional del enlace entre VM y el UER, porque ya existe un cifrado para paquetes que se transmiten entre la VM y el UE1 y pasan a través del UER.

[0095] De manera similar, en el relé UER, el cruce de los datos por las capas RLC R, una capa PDCP R, una capa IP, y una capa de aplicación, se reemplaza por el cruce de una sola capa RLC R. El relé UER retransmite la información al terminal UE1 sin necesariamente decodificarla/desencriptarla o descifrarla (si no conoce la configuración de la capa PDCP UE).

[0096] En el terminal UE1, hay una capa PDCP UE que se usa para la comunicación de extremo a extremo entre el UE1 y la VM. En este caso, la capa PDCP UE no está encapsulada en la capa PDCP del relé UER.

[0097] Además, debe tenerse en cuenta que el terminal UE1 fuera de la zona es controlado por la VM con la ayuda de las capas RRC o NAS (véase la figura 7) pasando a través del UER 20.

[0098] Las figuras 9 y 10 ilustran una tercera configuración denominada de «Multi-Hop relaying». El término «Multi-Hop relaying» designa una retransmisión de un terminal UE a través de varios relés UER, o una configuración con más de un salto. Aunque no esté representado en estas dos figuras, de una manera simplificadora, esto corresponde a una situación en que un usuario UE 18 B se conecta a través de un usuario UE 18 A (que a su vez se convierte en relé) para acceder a la red a través de un UER 20, como en las figuras 25, 27 y 30.

[0099] Se aplican los mismos elementos que para el plano de usuario y el plano de control de la segunda configuración para el plano de usuario y el plano de control según la tercera configuración. En lo sucesivo solo se detallan las diferencias.

[0100] En el plano de control, en la VM en la figura 9, la capa NAS se reemplaza por la capa NAS R, la capa RRC por la capa r Rc R y la capa PDCP UE por la capa PDCP R. En el plano de control, en la VM, ya no hay capa PDCP UE, NAS UE o RrC UE porque la VM ya no gestiona el UE 18A (u E1). En contrapartida, puede estar presente una función de control o «Ctr. f. » (servidor) en la VM para informar al UER de la nueva configuración - la misma función de control «Ctr. f. » (pero cliente) existe también en UER para poder acceder a las informaciones que provienen de la VM y opcionalmente para enviar informes (de configuración o medición) hacia la VM.

[0101]En otras palabras, en el plano de control de la figura 9, la VM ya no gestiona, por ejemplo, la movilidad de un usuario UE conectado a través del UER. La VM gestiona solamente las NAS R, RRC R y PDCP R y RLC R de un UER, y las NAS, RRC y PDCP de un UE se gestionan más bien por el UER. Sin embargo, la VM ya no transmite información RRC y NAS con destino al UE (al menos no de forma directa). Como alternativa, los protocolos NAS y RRC (total o parcialmente) con destino al UE se pueden transmitir mediante encapsulación en los protocolos NAS R y RRC R con destino al UER (por ejemplo, al contrario de la figura 5). En este caso, es el UER el que gestiona la retransmisión y, por lo tanto, la retransmisión del plano de control al UE.

[0102]En el relé UER, en el plano de control en la figura 9, los datos pasan a través de una capa PHY, una capa MAC, una capa RLC R, una capa PDCP R, una capa RRC R, una capa NAS R para los datos con destino al UER. Existe también una capa o función de control «Ctr. f. » (función «cliente», el equivalente de la función «servidor» que se encuentra en la VM), una capa NAS, una capa RRC, una capa (P) que es una forma abreviada de capa (PDCP), una capa genérica L2 y una capa genérica L1 para comunicar y gestionar UE1, por ejemplo, las configuraciones necesarias para la asignación de recursos, la seguridad, los informes de medición y la movilidad UE1. La configuración del UER para el que gestiona la capa NAS y RRC y PDCP de un UE se realiza mediante la función de control denotada por «Ctr. f. » (cliente). Alternativamente, si las informaciones a partir de protocolos NAS y RRC con destino al UE están encapsuladas (parcialmente) por la VM en los protocolos NAS R y RRC R entre la UER y la VM, la función de control «Ctr. f. » (cliente) en el nivel UER será también potencialmente responsable de extraer las informaciones NAS y RRC (desde NAS R y RRC R provenientes de VM) y de retransmitirlas hacia UE1 (en enlace ascendente, Ctr. f va a encapsular más bien la información RRC UE1 en RRC UER para la transmisión hacia la VM).

[0103]En el terminal UE1, los datos pasan a través de una capa genérica L1, una capa genérica L2, una capa (PDCP), una capa RRC y una capa NAS. En este contexto, las capas RRC y NAS de un terminal UE 18 A (UE1) son gestionadas por el UER.

[0104]Esto no se representa en la figura 9, pero si otro terminal UE 18 B (UE2) se conecta a UE 18 A (UE1) para acceder a la red a través de UER, UE 18 B (UE2) tal vez se configure para que sea gestionado por UER (UE1 realizará una operación de retransmisión tipo UER2 para su vecino UE2, a partir de UER; en este caso UE1 no es autónomo y es el UER que gestiona solo los NAS, RRC y PDCP para UE2 - como lo hace la VM para UE1 en las<configuraciones «single-hop» en las figuras 5 y/o 7) o por>U<e>18 A (en este caso UE1 es autónomo y gestiona solo los NAS, RRC y PDCP para UE2 - como lo hace el UER en las configuraciones «multi-hop» en la figura 9).

[0105]En el plano de usuario, en la VM de la figura 10, ya no hay capa PDCP UE que se reemplaza por una capa PDCP R. En efecto, la VM ya no gestiona el PDCP de un UE 18A (y ya no hay conexión PDCP de extremo a extremo entre la VM y UE). En la VM también hay una función Rel. f que se utiliza para configurar la retransmisión o la función de enrutamiento específico en el UER.

[0106]En el relé UER, en el plano de usuario en la figura 10, los datos pasan a través de otras capas entre la capa RLC R y la capa genérica L2. Estas capas son la capa PDCP R, la capa o la función f de Ret. por «relaying function» o «función de retransmisión», una capa IP, una capa de aplicación y después una capa de aplicación, una capa IP y una capa (P) que es una forma abreviada de capa (PDCP).

[0107]El relé UER puede utilizar una función Rel. f («Relaying function») para filtrar los paquetes recibidos desde el servidor de aplicación hacia su propia aplicación o hacia la capa necesaria para una transmisión hacia UE fuera de cobertura para la capa de aplicación de un UE fuera de cobertura u otro UE retransmitido por un UE fuera de cobertura (ver figuras 10 y 16).

[0108]Para el enlace descendente, en el plano de control de la figura 9, el relé UER (solo o bajo la configuración de la red realizada por la VM a través de una instrucción de configuración (hecha en el origen por el CC) gracias al módulo/función de control «Ctr. f. » (cliente) genera localmente la subcapa NAS, RRC y PDCP para controlar (por ejemplo, la movilidad, el scheduling u otros aspectos) directamente el UE fuera de cobertura. La función «Ctr. f. » se utiliza para la configuración/gestión de capas entre UER y UE (para configurar las capas UER y el nivel de control en un UER).

[0109]Para el enlace ascendente, en el plano de control de la figura 9, el UE informa las mediciones directamente al UER y es el UER el que toma las decisiones de HO o movilidad a través de los protocolos RRC y NAS.

[0110]Para el enlace ascendente, en el plano de usuario de la figura 10, el UE transmite paquetes IP a la red directamente a través del UER. Además, para que los gráficos de red en CC sean actualizados permanentemente (para que el CC tenga una vista de conjunto en toda la red), la función «f de Ret. » («Relaying function») añadida en un UER tiene el también el papel de retransmitir las mediciones efectuadas por UE (o<u>E<r>) en la interfaz UE-UER (ver Figuras 10 y 16, o ya no hay protocolos RRC y NAS directamente entre el UE y la VM, y/o si los RRC R y NAS R no transfieren/no encapsulan las mediciones RRC UE y NAS UE). Para el enlace ascendente, el segundo papel de esta función de retransmisión es filtrar los paquetes y dirigirlos a la capa de aplicación UER o a la red. De manera similar, para el enlace descendente, la función Rel. f («Relaying function») se añade en un UER para filtrar los paquetes y dirigirlos hacia la capa de aplicación UER o hacia el UE1.

[0111]En una implementación posible, la función Rel. f en el nivel VM y/o UER (y sobre todo en el plano de control) puede asimilarse o integrarse en la función de control «Ctr. f. ». Sin embargo, el papel de la función Rel. f está más en el plano de usuario que en el plano de control, y puede verse como una función de enrutamiento. En una situación multisalto esta función es esencial para retransmitir las mediciones en el plano de usuario desde el UE 18 A hacia la VM 10B, a través del UER 20.

[0112]En el terminal UE1, se utiliza opcionalmente una capa PDCP UE también denominada (PDCP), para una utilización directa entre UE y UER (y que desempeña el papel de una capa PDCP que normalmente se encuentra entre un terminal UE y una eNB clásica).

[0113]En esta configuración, es el relé UER el que implementa el control de los terminales UE fuera de la zona de cobertura. El relé UER tiene la capacidad de descifrar la información al terminal UE.

[0114]Como alternativa, la información UE se codifica en la aplicación y el relé UER no tiene la capacidad para descifrarla.

[0115]También es posible una cuarta configuración denominada de «Broadcast operation». El término «Broadcast» remite al caso de al menos un terminal UE conectado directamente al punto de acceso a la red, es decir, una configuración sin salto. En un modo de difusión, varios terminales UE pueden recibir la misma información (voz, datos, vídeo, etc.).

[0116]Se aplican los mismos elementos que para el plano de usuario y el plano de control de la tercera configuración para el plano de usuario y el plano de control según la cuarta configuración. En lo sucesivo solo se detallan las diferencias.

[0117]En el plano de usuario, en la VM, las capas RLC R, PDCP R, RRC R y NAS R se reemplazan por tres capas RLC, RRC y Na S.

[0118]Además, en este caso, no hay ningún relé UER que sirva como relé.

[0119]Cada entidad entre el terminal UE1, el terminal UE2 y el relé UER recibe los paquetes procedentes de la pila de protocolos formada por las capas PHY, MAC, RLC, RRC y NAS.

[0120]En el plano de control, en la máquina virtual 10B, las capas RLC R y PDCP R se reemplazan por una capa RLC.

[0121]Cada entidad entre el terminal UE1, el terminal UE2 y el relé UER recibe las capas PHY, MAC, RLC, IP y Apl.

[0122]Es posible una quinta configuración denominada de «Broadcast operation using eMBMS».

[0123]Se aplican los mismos elementos que para el plano de usuario y el plano de control de la cuarta configuración para el plano de usuario y el plano de control según la quinta configuración. En lo sucesivo solo se detallan las diferencias.

[0124]En el plano de usuario, las capas S1-AP y NAS se reemplazan por las capas SCTP y M3-AP tanto en la entidad MME como en el controlador CC.

[0125]Además, no hay instanciación de la capa NAS y, por lo tanto, no hay transmisión a través de dicha capa.

[0126]Estas diferencias se transportan fácilmente en el plano de control, que no se detalla adicionalmente.

[0127]Una sexta configuración permite tener un equivalente de la configuración «Multi-Hop relaying» (ilustrada especialmente por las figuras 9, 10, 15 y 16) en la que, para el plano de control, la capa RRC de un terminal UE 18A es gestionada por el relé UER 20 (como en las figuras 9 y 15) pero la capa NAS de un terminal UE 18A es gestionada por la máquina virtual VM 10B (como en las figuras 5, 7, 11 y 13). Esta sexta configuración corresponde a una configuración híbrida de la capa L3 entre una configuración de tipo «multi-hop» y una configuración de tipo «singlehop». Esto implica que las configuraciones de seguridad y movilidad están siempre formadas en parte por la máquina virtual VM 10B en lugar de un relé UER 20 y esto permite tener una capa<r>R<c>más reactiva, con protocolos más rápidos en términos de latencia. Además de estas configuraciones, pueden existir varias configuraciones, por ejemplo un modo de difusión o broadcast de un UER 20 para retransmitir la información hacia varios usuarios UE (esta serie de alternativas está marcada por la utilización opcional de la capa PDCP, e incluso (P) o (PDCP)).

[0128]Es posible trasponer las configuraciones anteriores con otras alternativas. Por ejemplo, según una realización, la entidad 10A transmite únicamente las capas PHY y no la capa MAC (ver las figuras 10 a 16), lo que corresponde por ejemplo, a una implementación con un RRH 10A.

[0129]Según otra realización, las PDU que provienen de la subcapa LTE RLC (y/o LTE MAC) son encapsuladas en PDU que pasan a través de una subcapa MAC Ethernet y transmitidas con la entidad 10A (RRH o TP). Según otra realización, la subcapa PHY/CPRI se reemplaza por una subcapa Lt2/Lt1 que opera con Ethernet.

[0130]La figura 17 ilustra un organigrama de funcionamiento del controlador CC que muestra un ejemplo de implementación de un procedimiento de determinación de una configuración de relés entre un nodo y los terminales.

[0131]Para ello, el controlador CC utiliza gráficos de red. Las figuras 18 a 23 son ejemplos particulares de gráficos de red. El ejemplo de las figuras 18 a 23 corresponde a una red con una estación base, dos terminales UE y un relé UER. Las figuras 18, 20, 22 pueden mostrar valores con prerrequisitos o requisitos del sistema, y las figuras 19, 20 y 23 pueden mostrar valores reales, que han sido medidos o estimados, y por lo tanto, valores adquiridos. Las figuras 18 a 23 son ejemplos y, por lo tanto, no limitantes, y se pueden realizar a diferentes niveles, capa de protocolo (L1 y/o L2 y/o L3), o entidad. Los gráficos también pueden representar una compilación de valores obtenidos por la combinación de una o más capas (varias capas vistas como un conjunto).

[0132]De abajo hacia arriba, a través de una multitud de capas de protocolo, es posible medir parámetros como ruido, interferencia, potencia, conectividad (véanse las figuras 22, 23), es posible determinar el rendimiento útil o adquirido (véanse las figuras 20, 21), se puede determinar el nivel de seguridad, o se puede determinar la latencia (véanse las figuras 18, 19).

[0133]El procedimiento incluye una pluralidad de etapas señaladas con los signos de referencia E0 a E7 y C1 a C3.

[0134]Las etapas E1, E3, E4 y E7 interactúan con una base de datos denominada DB. De manera más general, se interactúa en las etapas E1, E3, E4 y E7 con cualquier medio para guardar y mostrar la información necesaria.

[0135]La base de datos DB permite recopilar, actualizar y guardar la información relativa al menos a una entidad de la arquitectura de red.

[0136]Por ejemplo, la actualización y la recogida de información se realizan a través de una APl.

[0137]En la etapa de inicialización E0, cada terminal UE se registra y los requisitos en términos de servicio del terminal UE también se registran (potencialmente en una DB).

[0138]El registro es, por ejemplo, implementado por el controlador CC que recupera las informaciones gracias a la VM, de manera que entonces la VM representa el papel de una estación base.

[0139]Según el caso, los requisitos en términos de servicio (véase, por ejemplo, también TS 23.203 con los indicadores de clase de QoS, lo que se denomina QCI o identificadores de clase de QoS) son, por ejemplo, los requisitos en cuanto a BER (tasa de error de bits ("ItalicBit Error Rateltalic")), en cuanto a PER (tasa de error de paquetes ("ItalicPacket Error Rateltalic")), en cuanto a prioridad, los requisitos en cuanto a latencia, en cuanto a RSRP, RSRQ o en cuanto a rendimiento.

[0140]El registro se implementa, por ejemplo, usando un relé UER o un terminal UE que se convierte en un relé UER.

[0141]Por ejemplo, se supone que un segundo terminal UE2 entra en la arquitectura de red.

[0142]En la primera etapa de generación E1, se genera un gráfico de conectividad en la base de datos DB.

[0143]La generación es, según el caso, una creación o una actualización.

[0144]Las figuras 22 y 23 son ejemplos particulares de gráficos de conectividad (por ejemplo, implementados por el suministro de informaciones de conectividad) que combinan también aspectos de gráficos de medición (por ejemplo, implementados por el suministro de mediciones de potencia, de rendimiento o de relación señal/ruido). En el caso particular propuesto, el gráfico de conectividad es un gráfico que muestra las conexiones potenciales entre diferentes entidades y también contiene valores de relación señal/ruido (indicada por el acrónimo SNR) o relación señal/ruido más interferencia (indicada por el acrónimo SINR).

[0145]Según otro ejemplo, en lugar de medir la SNR, es posible medir la potencia utilizada, el valor del ruido o el valor de la interferencia, o un valor binario (es decir, conectado o no conectado), o el valor de otras métricas, como el CQI definido en el estándar 3GPP y que representa una eficiencia espectral asociada con el enlace, o cualquier otra métrica que dé una medida de la calidad del enlace.

[0146]Según el ejemplo propuesto con el segundo terminal UE2, la arquitectura de red ve que el primer terminal UE1 conoce la existencia del segundo terminal UE2, que está conectado a través del primer terminal UE1, pero la configuración del primer terminal UE1 como relé aún no ha finalizado en esta etapa. Solo se conoce el gráfico de conectividad, es decir, la topología.

[0147]En la etapa de elección E2, se selecciona una configuración de entre las cinco configuraciones estudiadas anteriormente.

[0148]Según otro ejemplo, en la etapa de elección E2, se escoge entre menos configuraciones, en particular tres, y por ejemplo, la primera configuración, la segunda configuración o la tercera configuración. En tal caso, las etapas E5 y E6 no son implementadas (o son incorporadas opcionalmente a las otras etapas o comparaciones que las siguen o las preceden).

[0149]Según otro ejemplo, también es posible reagrupar etapas, por ejemplo, E4 y E5, o que la salida del comparador C3 (y por lo tanto, la flecha entre C3 y E1) se utilice directamente como entrada del comparador C1 (y por lo tanto, otra flecha entre C3 y C1). También es posible que, en este ejemplo, las etapas E6 y/o E7 se incorporen a la comparación C3. Si ninguna configuración se considera beneficiosa para el sistema en C3, el algoritmo puede pasar directamente a la etapa C1 (y por lo tanto, sin realizar necesariamente las etapas E1 y/o E2).

[0150]Se supone, a modo de ejemplo, que el controlador CC elige la tercera configuración.

[0151]En la etapa de prueba C1, se prueba si un nuevo usuario ha realizado un registro.

[0152]Si se registra un nuevo usuario, la topología de la arquitectura se modifica y se implanta de nuevo la etapa E1 de generación.

[0153]En ausencia de nuevo usuario, se implanta la segunda etapa E3 de generación.

[0154]El ejemplo de las figuras 20 y 21 corresponde a diagramas de flujo.

[0155]En la etapa de comparación C2, se determina si es deseable una conmutación a otro transmisor que el elegido en la etapa de elección E2.

[0156]Como alternativa, tal conmutación se selecciona en función de otros parámetros, como la información de latencia, la calidad del servicio, o el rendimiento.

[0157]A modo de ejemplo, se supone que la única conmutación posible es entre el otro terminal UE y el relé UER, o viceversa.

[0158]Para determinar la conveniencia de tal conmutación, se compara la calidad de la transmisión entre los dos terminales UE y entre el terminal UE y el relé UER.

[0159]Un criterio de comparación es, según un caso particular, la potencia transmitida.

[0160]Según un ejemplo más refinado, para evitar los problemas de conmutación consecutiva o los efectos de «ping-pong» que los acompañan o las conexiones/desconexiones/reconexiones consecutivas al mismo punto de acceso (UE, UER, eNB, VM)) o a diferentes puntos de acceso, la comparación se implanta durante un tiempo predeterminado y puede utilizar asimismo parámetros como, por ejemplo, histéresis y desfase (como por ejemplo en TS 36.331).

[0161]Según otro ejemplo, en la figura 33 se implanta un esquema con una implementación potencial para la etapa de comparación C2, en la que 330s representa la entrada y 334s la salida del algoritmo. La etapa de comparación 331c determina (para cada UE retransmitido, un UE retransmitido o todos los UE retransmitidos) si la potencia de un vecino UE, UER, eNB (o VM) es superior a un umbral s1. Si es así, el algoritmo pasa a la etapa de comparación 332c que determina si la latencia estimada excede un umbral s2 para el nuevo punto de acceso seleccionado (vecino UE, UER o eNB). En caso afirmativo, el algoritmo pasa a la etapa de comparación 333c en la que verifica si la banda disponible (usando el vecino UE, UER y/o eNB) excede un umbral s3 que representa el flujo (mínimo) necesario para retransmitir a los usuarios que se conectan a estos (nuevos) puntos de acceso. Si el resultado de comparación 333c es positivo, la decisión de conmutación (o HandOver por «HO») será positiva, y en caso contrario se rehace el procedimiento durante un periodo predeterminado para encontrar otra opción, si existiera.

[0162]Los elementos 31d, 32d y 33d son DB que suministran permanentemente a los comparadores 331c, 332c y 333c información 331i, 332i, 333i relativa a la potencia medida, la calidad del enlace, como, por ejemplo, RSRP, RSRQ, información sobre la selección de relés y las opciones disponibles como otros puntos de acceso potenciales 331i, o con respecto a la latencia o información sobre el número de saltos del 332i, o información sobre el flujo necesario por servicio y por usuario, dispositivo o entidad 333i. Además de estos elementos, el módulo 338e es responsable de la selección y/o reselección de otro punto de acceso (UE, UER, eNB) para otra configuración potencial.

[0163]Cuando se determina que es conveniente una conmutación, se implanta la etapa E4 de conmutación mientras que cuando se determina que una conmutación no es conveniente, se implanta la etapa E6 de verificación.

[0164]Suponiendo que se desea una conmutación del terminal UE2 al relé UER, esta conmutación se implementa durante la etapa de conmutación E4.

[0165]A continuación, se implementa una tercera etapa de generación E5, y se genera un gráfico de latencia como se ilustra en las figuras 18 y 19.

[0166]La creación o actualización del gráfico de latencia tiene en cuenta el número de conmutaciones consecutivas, la pérdida temporal de la comunicación y la latencia de extremo a extremo entre diferentes elementos.

[0167]En el ejemplo ilustrado, la latencia disminuye para el terminal UE2 ya que el terminal UE2 está conectado directamente al relé UER.

[0168]Entonces se implementa de nuevo la primera etapa E1 de generación para actualizar el gráfico de conectividad.

[0169]En el ejemplo ilustrado, el terminal UE1 está conectado al relé UER, el relé UER también está conectado al terminal UE2 y a la entidad VM.

[0170]Se implanta de nuevo la etapa E2 de elección, de manera que el controlador CC elige la primera configuración. El controlador CC configura entonces la VM para que se implante la primera configuración.

[0171]En el caso en que se implante la etapa E6 de verificación (sin conmutación), entonces se verifica si es posible mejorar la configuración.

[0172]Esto permite verificar si una configuración multi-hop puede ser transformada en configuración singlehop y a continuación en modo difusión si esto no ha sido ya resuelto por la conmutación (porque el enlace no era tan malo). Esta es una verificación para realizar una optimización complementaria. Por ejemplo, el controlador CC puede decidir simplemente eliminar la capa PDCP (en una VM o un terminal UER) observando que varios terminales UE reciben la misma información desde un terminal de relé UE-R (o VM). Esto corresponde a un modo de difusión (a varios destinos al mismo tiempo), y la ventaja es no utilizar diferentes recursos para transmitir una única información varias veces (es decir, varias transmisiones de unidifusión para transmitir lo mismo).

[0173]Así, en la etapa de prueba C3 se prueba especialmente si es posible una configuración de tipo «singlehop» (prueba C3). Esto es posible cuando el relé UER está estático, cuando los terminales UE1, UE2 y el relé UER se desplazan juntos (por ejemplo, están en el mismo vehículo), o cuando los terminales UE están muy cerca del relé UER.

[0174]Cuando esto es posible, el algoritmo (implementado en el CC) instruye el cambio de configuración. Esto genera un cambio de conectividad en el sistema. Por lo tanto, el algoritmo vuelve a la primera etapa de generación E1 para actualizar el gráfico de conectividad. De lo contrario, el algoritmo pasa a la etapa E7 durante la cual se transmite un mensaje de configuración desde el controlador CC para que el relé UER (o VM), por ejemplo, elimine/active la capa PDCP según corresponda. Una red puede tener uno o más controladores CC, pero en este caso habrá un controlador general (global) para controlar y distribuir la actividad de cada controlador CC (local).

[0175]A continuación de la etapa E7 se implanta de nuevo la etapa E2 de elección.

[0176]Según otro ejemplo, si se instruye el cambio de configuración, por ejemplo, en modo de difusión (respectivamente sin difusión) en C3 para un UER y/o VM, el algoritmo pasa a E7 (este es el caso para el modo de difusión que no cambia necesariamente la topología). Como esto no conlleva un cambio de conectividad en el sistema, basta con ir directamente a la etapa E2 que simplemente tendrá en cuenta el paso de un modo sin difusión a un modo con difusión (o de un modo con difusión a un modo sin difusión). En este caso, durante la etapa E7, se transmite un mensaje de configuración desde el controlador CC para que el relé UER (o VM), por ejemplo, elimine/active la capa PDCP según corresponda. De lo contrario, si no se instruye el cambio de configuración en C3, el algoritmo vuelve a la primera etapa de comparación C1 1) para actualizar el gráfico de conectividad si, por ejemplo, un nuevo usuario realiza un registro, o 2) para pasar a la etapa E3 si un usuario no realiza un registro y, por lo tanto, el gráfico de conectividad y/o la topología no cambian.

[0177]El procedimiento es así capaz de ser implantado de modo continuo. Tal implantación proporciona bucles cuya velocidad de implantación es regulable. La periodicidad de implantación se elige suficientemente baja para permitir que las entidades entren en la configuración elegida por el controlador CC. Una periodicidad de implantación típica está comprendida entre 100 ms y 300 ms. Pueden contemplarse periodicidades de implantación todavía más lentas en función, por ejemplo, del tipo de despliegue, las capacidades del material presente, la movilidad de los nodos y en particular de los relés.

[0178]Por lo tanto, el procedimiento permite controlar y adaptar la configuración de la arquitectura de red de forma permanente.

[0179]Para ello, se utilizan gráficos de red, que son herramientas que permiten visualizar y analizar el estado de una red.

[0180]En otros términos, por medio del procedimiento propuesto, los gráficos de redes se utilizan para configurar la VM y el relé UER efectuando en el relé single-hop, multi-hop o broadcast.

[0181]Más precisamente, el procedimiento permite determinar, en una arquitectura dotada de un relé UER, cómo controlar un terminal UE que está fuera de cobertura. En particular, debe determinarse si es más ventajoso controlar el terminal UE con el relé UER o la entidad eNodoB/VM. Tal determinación permite, en particular, encontrar un compromiso entre varios requisitos contradictorios, tales como el flujo, la latencia, una buena movilidad de los terminales UE, siendo el objetivo final garantizar una buena calidad de servicio. La calidad del servicio generalmente se describe según una función de coste (no detallada aquí) que se aplica a los flujos de datos que circulan en el sistema y a los parámetros del propio sistema (por ejemplo, consumo de energía o niveles de batería de los terminales, capacidad de cálculo y memoria restante, etc.), y tiene en cuenta en su formulación las métricas de medición de calidad deseadas.

[0182]A modo de ejemplo, en las figuras 31 y 32, se propone un mecanismo de configuración de capas en el nivel UER 20 y VM 10B con ayuda de algunas etapas E1 y E2 en el CC 22 y las funciones de control «Ctr. f» en UER 20 y VM 10B como se representa en las figuras 5-15. A modo de ejemplo, las figuras 31 y 32 muestran configuraciones denominadas «single-hop» y «multi-hop» y el paso posible entre las diferentes configuraciones.

[0183]En la figura 31, a modo de ejemplo, se muestra un primer UE1 (UE 18A) en fase de registrarse a través de UER 20 (o de conectarse, por ejemplo, al nivel L2 (por ejemplo, MAC) al UER) usando el mensaje de señalización 3101. Una vez que el UE se declara/realiza el registro y/o es detectado por el UER, el UER 20 informa al CC 22 (usando el protocolo RRC o la función Rel. f, por ejemplo) utilizando el mensaje de señalización 3102. En la etapa E1 (responsable de actualizar los gráficos de conectividad), el CC 22 conoce la topología pero aún no ha elegido la configuración. A continuación del mensaje 3102 y en la reactualización de gráficos en la etapa E1, en la etapa E2 el controlador CC 22 decide una configuración denominada «single-hop». Usando los mensajes 3103 y 3104 (transmitidos usando la capa de control y/o las API o funciones de control F. F y Ctr f.), el CC 22 configura localmente la VM 10B y el UER 20 para implantar el modo de transmisión «single-hop». Más precisamente, 1) el CC 22 activa el RRC UE1 y el PDCP UE1 para el usuario UE1 (UE 18A) en la VM y 2) el CC 22 configura UER 20 para que retransmita los paquetes UE1 (paquetes que el UER no puede decodificar con el PDCP UER). En este punto, representado por la conexión de extremo a extremo 3106, el UE1 está conectado a la VM utilizando un protocolo RRC UE 1 que se transmite a través de un PDCP UE1 que es transmitido por el UER en el PDCP UER a la VM. Esto corresponde a una configuración de tipo «single-hop» descrita por ejemplo por las figuras 5-6 y 24. Debe recordarse que en este punto, el UE1 está completamente gestionado por la VM (y no por el UER) en lo que respecta, por ejemplo, a la movilidad y otros aspectos del acceso a la red.

[0184]Entre tanto, un segundo UE2 (UE 18B) efectúa un procedimiento de registro a través de UE1 (o se conecta al nivel L2 (por ejemplo, MAC) al UE1) usando el mensaje de señalización 3105. Después de la conexión 3106 con la VM, el UE1 (U<e>18A) puede informar directamente a la VM 10B a través de un mensaje de señalización 3107 (por un mensaje de tipo RRC, o usando la función Rel. f o Ctr. f) que el UE2 (UE 18B) quiere acceder/necesita acceder a la red. En un solo mensaje 3107 u otro mensaje 3108, la VM 10B informa al CC 22 de que actualiza los gráficos E1. A continuación de esta actualización y de la nueva topología, CC 22 decide reconfigurar la VM 10B y el UER 20 para otro tipo de retransmisión, en la etapa E2. Más precisamente CC 22 decide aplicar una estrategia de tipo «multi-hop», y 1) utilizando el mensaje 3109 y la función «Ctr. f» en el nivel VM, el CC desactivará el RRC y el PDCP UE1 en la<v>M 10B, y 2) utilizando el mensaje 3110 y la función «Ctr. f» en el nivel UER, el CC activará el RRC y el PDCP UE1 en el UER. Esto corresponde a una configuración de tipo «multi-hop» descrita por ejemplo por las figuras 9-10 y 25. Debe recordarse que en este punto (es decir, en la conexión 3111), el UE1 está completamente gestionado por el UER (no por la VM) en lo que respecta, por ejemplo, a la movilidad y otros aspectos del acceso a la red. En otras palabras, el RRC UE1 es gestionado por el UER (y por lo tanto, el UER también implementa las capas RRC, (PDCP), NAS UE1, etc. entre el UE1 y el UER). Por lo tanto, el plano de control para el UE1 se realiza transmitiendo el protocolo RRC UE1 a través del PDCP UE1 directamente al UER, y el UER podrá codificar/decodificar, cifrar/descifrar directamente el UE1 y también controlar el UE en todo lo que respecta, por ejemplo, a la movilidad. A continuación, para enviar informaciones hacia la red, el UER utilizará sus propias capas de protocolos pero sin utilizar capas/protocolos suplementarios UE para la interfaz entre UER y la entidad VM/eNodoB.

[0185]Posteriormente, la figura 32 muestra un ejemplo similar a la figura 31. Los intercambios 3201-3205 son similares a s3101-3104 y 3106. Lo que cambia, por el contrario, es que el UE2 (UE 18B) se conecta directamente al UER 20 a través del mensaje 3206 (y no como en la figura 31 en la que el UE2 se conecta al UE1 (UE 18A) utilizando el mensaje 3105). Por lo tanto, siguiendo el mensaje 3206, el UER 20 informa al CC 22 (utilizando, por ejemplo, un protocolo de tipo RRC o Rel. f) usando el mensaje 3207 y a continuación 3208. En este punto, solo el UE1 es controlado/gestionado por la red/VM pero para el UE2, la red aún no ha decidido qué configuración usar para esta topología. CC 22 actualiza los gráficos (por ejemplo, en el nivel E1) y decide en el nivel E2 aplicar una estrategia de tipo «single-hop» y no «multi-hop» (como en la figura 31). Así, utilizando los mensajes de señalización 3209 y 3210 y las dos funciones de control «Ctr. f» en la VM y UER, CC 22 activa el RRC y el PDCP UE2 en la VM, y a continuación el UER 20 para que retransmita los paquetes UE2 (paquetes que no puede decodificar con el PDCP UER). En este estado, el UER 20 aplica la estrategia de retransmisión «single-hop» a los dos usuarios UE1 y UE2. En otras palabras, los dos UE (UE1 y UE2) están en conexión RRC (y PDCP) con la VM, (pasando a través del UER 20), lo que corresponde a la elección de configuración representada en la figura 26 (y que siempre es aplicable a las figuras 5-6 y/o 7-8). A modo de ejemplo, en la etapa 3211, el plano de control UE2 (UE 18B) será transmitido por el UER utilizando un protocolo RRC<u>E2 en PDCP UE2 en el PDCP UER hacia la VM. En esta configuración, el UER 20 no podrá (normalmente) decodificar/descifrar la información transmitida entre el UE2 y la VM.

[0186]A modo de ejemplo, se considera una topología correspondiente a un segundo terminal UE2, un primer terminal UE1, el relé UER y la entidad eNodoB, estando el segundo terminal UE2 conectado directamente al primer terminal UE1 que a continuación se conecta al relé UER y a la entidad eNodoB para un acceso a la red. En tal topología, se encuentra que los canales son mejores en cuanto a calidad de servicio por la proximidad de las entidades, pero el paso a múltiples saltos genera un problema de latencia y se solicita al relé UER que realice tres comunicaciones, lo que corresponde a un problema de recursos en este ejemplo específico. Esto revela que una topología dada y la elección de efectuar una comunicación a través de un punto de acceso u otro influirán en la calidad de servicio de los servicios soportados a través de las comunicaciones entre los nodos según las configuraciones posibles de la arquitectura en red presentada en la presente descripción.

[0187]Además, la elección de los protocolos utilizados también está implicada en la calidad de servicio resultante. Típicamente, el uso de una capa PDCP implica operaciones de encriptación/cifrado que llevan tiempo.

[0188]Una consecuencia de esta constatación es que el controlador CC por medio del procedimiento se adapta permanentemente si el protocolo de nivel 2 (por ejemplo, por medio de una capa PDCP) o de nivel 3 (por ejemplo, por medio de una capa RRC o NAS) es implementado en la V<m>o en el nivel del relé UER.

[0189]Por último, cabe señalar que, durante una configuración de las capas de la VM, el controlador CC puede decidir eliminar la retransmisión de la capa de nivel 3 para un terminal UE fuera de la zona, para añadir o eliminar una capa PDCP UE en la VM y, de manera más general, para añadir o eliminar cualquier parte de la pila de protocolos o capa. Las mismas acciones son posibles para el relé UER. Los diferentes escenarios se ilustran particularmente en las figuras 24 a 30.

[0190]Por lo tanto, como aparece en la figura 24, que es una figura simplificada (las capas base y la capa NAS no se muestran), la VM presenta nuevas funcionalidades, en particular las capas RRC, PDCP para un terminal UE en la cuarta zona Z4.

[0191]Más precisamente, en el enlace descendente, la VM garantiza la transferencia de los paquetes procedentes de las capas NAS y RRC al relé UE-R en la capa PDCP UE-R y después en la capa RLC UER. A continuación, los paquetes RLC UE-R 20 se encapsulan en (X/IP), después se transmiten a través de L2t/L1t, se decodifican por el TP que realiza las operaciones inversas L1t/L2t e IP/X y se retransmiten en la MAC y PHY del TP y al mismo tiempo.

[0192]La VM asegura, por otra parte, la transferencia de la capa NAS y RRC para el terminal UE 18 A en la capa PDCP UE, y a continuación los paquetes de la capa PDCP con destino al terminal UE 18A son encapsulados en la capa PDCP UER, y después en la capa RLC UER. Los paquetes de la capa RLC UER se encapsulan en la capa X/IP, después se transmiten en la capa L2t/L1t, se decodifican por el TP que realiza las operaciones inversas L1t/L2t e IP/X y se retransmiten en la MAC y PHY del TP (de abajo hacia arriba y después de arriba hacia abajo).

[0193]El relé UER asegura así la recepción de la capa PHY, después de las capas MAC, RLC, PDCP UER, RRC y NAS que provienen de la VM. El relé UER garantiza también la transferencia de las capas de paquetes de la capa PDCP UE que contienen información de control RRC, NAS y datos IP.

[0194]En esta configuración, el relé UER no es capaz de descifrar y/o decodificar paquetes en capas con destino a un terminal UE.

[0195]En el enlace ascendente, un terminal UE 18A transmite las capas NAS y RRC en la capa PDCP UE y a continuación se encapsulan en las capas genéricas L2 y L1 y son desencapsuladas por el relé UER que realiza los tratamientos de nivel 1 o 2 para recuperar los paquetes que provienen de un terminal Ue 18. El relé UER recupera los paquetes de la capa PDCP UE pero no es capaz de decodificar o descifrar estos paquetes con su capa PDCP UER.

[0196]El relé UER es capaz también de transmitir o de transferir los paquetes que provienen del terminal UE 18A (que ya están cifrados con la capa PDCP UE) en la capa PDCP UER y a continuación las capas RLC UER, MAC UER, PHY UER hacia la VM, pasando a través de las capas del punto de acceso TP (de abajo arriba o de arriba abajo).

[0197]Por otra parte debe observarse que, en esta configuración, el relé UER no es capaz de descifrar las capas con destino al terminal UE 18A. Solo la VM es capaz de esto (a través del uso previo de las capas PDCP UER y PDCP UE).

[0198]Por lo tanto, en la configuración de la figura 24, el uso de las capas RRC UE1 y PDCP UE1 es original.

[0199]Asimismo, en la figura 25, el uso de las capas RRC UE1, PDCP UE1, RRC UE2 y PDCP UE2 es original.

[0200]De manera similar, en la figura 26, el uso de las capas RRC UE1, PDCP UE1, RRC UE2 y PDCP UE2 es original.

[0201]Se aplican observaciones similares a las figuras 27 a 30, en las que lo que se muestra es original.

[0202]A través de la ilustración de las figuras 24 a 30, será evidente que el procedimiento permite, por lo tanto, una adaptación constante de la configuración de comunicación a la situación actual de la arquitectura de red mediante el uso de los gráficos mencionados previamente. Las flechas F1 y F2 pueden representar vectores de desplazamiento que indican una movilidad potencial.

[0203]Además, se pueden usar otros gráficos tales como gráficos de conectividad, gráficos de interferencias, gráficos de potencia medida, gráficos de calidad de transmisión, gráficos de flujo, gráficos de latencia y gráficos de discontinuidad del servicio.

[0204]El procedimiento se basa en el uso de tres gráficos de redes distintas.

[0205]A continuación se describen las ventajas de la arquitectura y de su funcionamiento.

[0206]En comparación entre las arquitecturas de las figuras 1 y 4, la arquitectura convencional de la figura 1 se ha modificado para ofrecer un mayor número de funcionalidades, como la retransmisión a la entidad UE.

[0207]La arquitectura de la figura 4 es una arquitectura con nuevas funcionalidades pero un impacto limitado en los equipos o entidades existentes (y para los usuarios, los procedimientos son transparentes). De hecho, la arquitectura permite una mayor flexibilidad y adaptabilidad en cuanto al relé sin demasiados cambios. En particular, las nuevas entidades UER, V<m>y CC gestionan todas las nuevas configuraciones sin afectar a las demás entidades de la red central como las entidades S-GW, P-GW o MME.

[0208]En la arquitectura de la figura 4, la estación base está separada en varias partes, una de las cuales es virtual. La virtualización de las funciones de las capas L1/L2/L3 permite reducir el coste de implementación y operación de la red. Formulado de otro modo, la máquina virtual sirve para simplificar la red de acceso radio (RAN por «Radio Access Network»).

[0209]Además, la VM se puede reconfigurar fácilmente. De hecho, es fácil añadirle capas según las necesidades del usuario. De hecho, la VM permite implementar una entidad eNodoB que es flexible y adaptable, adaptable en el sentido de que es posible añadir o quitar capas, o cambiar parámetros más rápidamente en diferentes capas. Incluso es posible proporcionar varias instancias de la misma VM, configuradas de manera diferente, para la misma estación base, o posiblemente una o más instancias por usuario.

[0210]Además, las ventajas de una arquitectura flexible y fácilmente adaptable son (al menos) el hecho de tener una flexibilidad y una adaptabilidad a una multitud de situaciones y escenarios de despliegue, el hecho de tener una arquitectura fácilmente reconfigurable (por ejemplo, para las redes que se autorreconfiguran solas sin una intervención humana suplementaria, por ejemplo, SON o «Self Organizing Networks»).

[0211]Además, en la arquitectura, la introducción de un controlador adicional (el controlador CC) reduce los problemas de latencia y simplifica el procedimiento de control normal que involucra a la entidad MME, y reduce considerablemente la señalización requerida en la parte de la red central.

[0212]Más concretamente, el controlador CC se interpone entre la entidad MME y la VM con el objetivo de extraer información relevante de la entidad MME y convertirla en información relevante para la VM. El propósito de dicha interposición del controlador CC entre la VM y la entidad MME es reducir el impacto sobre la entidad MME y controlar las capas y la configuración de las capas de la VM y el punto de transmisión TP. El controlador CC es también responsable de la distribución óptima de las capas entre el punto de acceso red 10A y la VM (por ejemplo, opción TP que implementa las capas PHY, MAC y VM para las capas superiores a partir de la capa RLC, u opción RRH que implementa la capa PHY y VM para las capas altas a partir de la capa MAC).

[0213]El controlador CC transmite la información procedente de la entidad MME a la VM y de la VM a MME a través de la pila de protocolos de control entre la VM y el controlador CC, pero también añade funciones de configuración de las capas y parámetros de las capas, configuración de mediciones, configuración de informes de mediciones para extraer información útil de diferentes capas implementadas en la VM. Todas estas configuraciones e informes se pueden realizar a través de una interfaz de programación o API. Se pueden tener también dos entidades MME (por ejemplo, una entidad MME para un UE y otra entidad MME para el relé UER) y dos capas NAS: un NAS para UE y un NAS para UER. El papel del CC es también hacer creer a la red que el terminal UE fuera de cobertura está siempre bajo el control de la red, y la entidad MME «ve» el terminal UE como siempre conectado directamente a ella (no ve que es retransmitido por un relé UER que puede incluso pertenecer a otro operador y que no está bajo el control de la entidad MME de origen de un terminal UE), incluso si no fuera así en realidad.

[0214]El controlador DC es capaz de configurar funcionalidades en tiempo real o que operen en tiempos más lentos. El controlador CC utiliza gráficos de red para tener informaciones globales en todo el conjunto de la red.

[0215]La arquitectura de red es una arquitectura de red de tipo LTE autoconfigurable. La reconfigurabilidad de la arquitectura de red permite la implementación de varias configuraciones de retransmisión. Estas configuraciones son de salto único, múltiples saltos, difusión o comunicación directa con la entidad eNodoB.

[0216]Sintéticamente, la información obtenida de los gráficos de red a nivel del controlador CC se utiliza con el propósito de realizar modificaciones en la VM para controlar la retransmisión. La VM implementa la totalidad o parte de la pila de protocolos de una entidad eNodoB.

[0217]Cabe señalar que la arquitectura propuesta se transpone fácilmente para arquitecturas distintas de una arquitectura LTE. En particular, la arquitectura utiliza en ciertas realizaciones protocolos pertenecientes a Ethernet o WiFi.

[0218]Cabe señalar que la capa genérica puede basarse en tecnologías como WiFi, WiMax, OFDM, SC-FDMA, CDMA, FlashLinQ, ProSe (por ejemplo, PC5), 5G (FBMC, OFDM filtrada, GFDM, UFMC, etc.), Bluetooth, BLE (Bluetooth de baja energía (Bluetooth Low Energy)), etc.

[0219]Cabe señalar que las configuraciones de las capas, el tipo de retransmisión, y/o las configuraciones de los informes de medición, y/o las medidas de conectividad, topología, calidad del enlace de radio, flujo, latencia y seguridad, etc., se pueden hacer periódicamente (a intervalos periódicos) o eventualmente (por ejemplo, superando el umbral de un parámetro).

GLOSARIO

[0220]API: acrónimo de «Application Programming Interface» por «interfaz de programación». La API es la interfaz que transmite las configuraciones de las entidades de red, de sus capas y de la infraestructura desde o hacia el CC. lA API es también la interfaz que transmite las mediciones y los datos estadísticos que provienen de las entidades de la red, las mediciones y los datos estadísticos que se refieren al estado de las entidades de la red (RAN o red núcleo) y los enlaces establecidos entre ellas. LA API tiene el papel de asegurar la transmisión de los parámetros pertinentes entre el controlador (CC) y la red, o entre el controlador (CC) y las entidades de infraestructura; la API tiene también un papel para suministrar la configuración de las entidades de la red y de las infraestructuras pertinentes. Por un lado, la API se encarga de procesar los paquetes para extraer medidas o estadísticas, y por otro lado, la API se encarga de configurar capas en diferentes niveles (por ejemplo, PHY, L1, L2 y/o L3 según el caso y/o la entidad).

[0221]BBU: acrónimo de «Base Band Unit» por «unidad de tratamiento en banda de base».

[0222]Capas de protocolo, más sencillamente llamadas capas: se trata de una capa que implementa un protocolo que realiza operaciones en un paquete de datos. En general, a menos que se indique lo contrario, las capas mencionadas en la presente solicitud son capas que se ajustan al estándar LTE, es decir, que implementan las operaciones de este estándar.

[0223]Broadcast: difusión, transmisión del mismo flujo de datos hacia varios usuarios; configuración de tipo difusión.

[0224]CC: acrónimo de «Controlador Central» o «coordinador central», también descrito en el texto como «controlador CC». El CC controla parámetros diferentes de diferentes entidades de la red o de la infraestructura (Multi-RAT (Radio Access Technology), las diferentes capas, puntos de acceso, entidades de redes, conmutadores (o switches)) gracias a las API. El CC recopila y coordina configuraciones de las entidades introducidas anteriormente aplicando las políticas de gestión de recursos definidas en la red para toda la red o una parte de la red (por ejemplo, para el uso del espectro, la gestión recursos, la prioridad de un servicio). El CC es capaz de recopilar información de la red y de la infraestructura a través de las API, y configurar, crear y actualizar gráficos de red entre dos tareas de control consecutivas y/o entre diferentes instancias de control (en el caso en el que la creación de gráficos se distribuye en varias estructuras, en varias entidades, por ejemplo, una primera entidad que tiene una vista local realiza mediciones más precisas pero solo transmite información estadística, por ejemplo, de tipo promedio y/o varianza a la segunda entidad que tiene una visión global). El CC puede suministrar gráficos para cada distribución específica de la red de acceso (por «slice RAN») y gráficos específicos simplificados, con una vista local de la red para las aplicaciones de red (por ejemplo, por medio de la API). El controlador CC también es responsable de la separación funcional específica de diferentes entidades, por ejemplo, para el eNB en una configuración distribuida (por ejemplo, un eNodoB puede ser configurado por el cC según una configuración distribuida con los TP/RRH, o según alguna otra configuración (por ejemplo, tipo nube-RAN con una BBU por«unidad de banda base»)). El controlador CC se presenta en la descripción como una sola entidad, pero como alternativa, el controlador CC puede descomponerse (como funcionalidad pero también como entidad) en dos partes: una parte que implementa funcionalidades para aplicaciones lentas y otra parte que implementa funcionalidades para aplicaciones en tiempo real.

[0225]CPRI: acrónimo de «Common Public Radio Interface» por «interfaz de radio pública común».

[0226]Ctr. F.: acrónimo de «Control Function» por «función de control». Esta función de control está relacionada con «Capa de control» por «capa de control». Más precisamente, en la capa «Ctr Layer», las configuraciones se realizan por una función de control denominada Ctr. F. La función de control acepta en entrada parámetros que provienen de la API, ejerce su función de control y transmite las instrucciones/informaciones hacia las diferentes capas de red utilizando la capa de control y API. Dicho de otro modo, la función de control configura la parametrización de las API, parametrización que es necesaria para controlar y extraer dinámicamente los parámetros de diferentes capas y configurar las medidas en las diferentes capas de las diferentes entidades, también es responsable de la configuración de informes de medida, y ejerce su función de control sobre el uso o no de un protocolo, una subcapa u otra función de red.

[0227]Capa de control: acrónimo de «Control Layer» por «capa de control». Se trata de una capa que implementa el protocolo que se encarga de transmitir el plano de control entre el CC y la VM. Este puede ser, por ejemplo, un protocolo de tipo X2-AP o S1-AP que se utilizan normalmente en las interfaces X2-C o S1-C/S1- MME. Al contrario que Capa de control, Ctr. F. es una función responsable de la aplicación del protocolo utilizado por el Capa de control, se trata así de una función de un nivel superior.

[0228]Ctr. f. : acrónimo de «Control function» por «función de control» entre el UER y la VM (a diferencia de «Ctr. F» entre VM y CC). La función de control o «Ctr. f. » (servidor) en la VM para informar al UER de la nueva configuración - la misma función de control «Ctr. f. » (pero cliente) existe también en UER para poder acceder a las informaciones que provienen de la VM y opcionalmente para enviar informes (de configuración o medición) hacia la VM. La configuración del UER para que gestione la capa NAS y RRC y PDCP de un UE es realizada por la función de control denotada por «Ctr. f. » (cliente). Alternativamente, si las informaciones a partir de protocolos NAS y RRC con destino al UE están encapsuladas (parcialmente) por la VM en los protocolos NAS R y r Rc R entre la UER y la VM, la función de control «Ctr. f. » (cliente) en el nivel UER será también potencialmente responsable de extraer las informaciones NAS y RRC (desde NAS R y RRC R que provienen de VM) y de retransmitirlas hacia UE1 y/o a la inversa (encapsular la información UE1 en UER para la transmisión hacia la VM).

[0229]eNodoB: acrónimo de «enhanced NodeB», equivalente de una estación base en LTE (en UMTS es un NodoB). De manera similar, el acrónimo eNB (eNodoB) designa una estación base o un punto de acceso («access point»). Según el tipo de arquitectura en red, pueden utilizarse otros términos bien conocidos en lugar de «eNodoB» o «eNB». Por ejemplo, se pueden utilizar términos como estación base o punto de acceso. El término «eNodoB» se utiliza en este documento para hacer referencia a una entidad de una arquitectura en red que suministra un acceso inalámbrico a terminales a distancia.

[0230]gráfico de conectividad: un gráfico de conectividad es un gráfico que conecta entidades de una arquitectura en red entre sí mientras exista una conexión entre ellas. Según el caso, la conexión es física, inalámbrica o por cable. De manera sencilla, un ejemplo de gráfico de conectividad es un gráfico para el que un trazo indica la existencia de una conexión entre dos entidades y su ausencia indica que las dos entidades no están conectadas (o un gráfico que indica por valor «1» la presencia y por valor «0» la ausencia de una conexión). La conectividad se puede determinar, por ejemplo, en la subcapa MAC, en la capa L2 (después del procedimiento de sincronización en L1 y/o después del acceso inicial en la MAC). También se puede definir un gráfico de conectividad por la superación de un valor físico («1» si un valor determinado por medición supera el umbral definido por un valor físico; «0» si no supera el umbral).

[0231]gráfico de latencia: un gráfico de latencia es el equivalente al gráfico de conectividad sustituyendo la conexión por la latencia. La latencia se puede medir en la capa L3 (o en algunos casos en L2, por ejemplo, en la capa MAC para el protocolo HARQ con acuse de recibo o sin acuse de recibo, o en L1 para acceso síncrono o asincrónico).

[0232]gráfico de medición: por este término se entiende un gráfico con todos los enlaces disponibles entre diferentes entidades y con al menos una medición, y especialmente valores de potencia, calidad de servicio, informes de señal/ruido, interferencia, rendimiento.

[0233]gráfico de red [también denominado «network graph» en inglés]: El gráfico de red representa una visión sintética y dinámica de los parámetros y de los enlaces de la red relacionados con los rendimientos actuales de la red o con las exigencias que se desea alcanzar, en relación con los intercambios de información entre dos entidades entre el punto de acceso, el relé y

[0234]los terminales. Típicamente, los gráficos de red dan una vista del plano de datos, pero también se pueden hacer para el plano de control cuando su operación involucra a varias entidades de red que se comunican entre sí. La utilización de un gráfico de red puede comprender también el plano de los recursos computacionales/de banda, etc., el plano de los servicios/aplicaciones, las informaciones sobre la infraestructura por ejemplo, los recursos disponibles, las indicaciones relativas a los parámetros de las entidades y/o de la infraestructura (por ejemplo, el nivel de batería) o las realizaciones/implementaciones diferentes de la infraestructura. El gráfico de red puede ser un solo gráfico (con una vista global) o estar descompuesto en varios gráficos (varias vistas locales) en una o más distribuciones de la red, en una o más instancias (en el caso en que la creación de gráficos se distribuya en varias estructuras, en varias entidades). Un gráfico de red también puede combinar varios gráficos o varios valores de gráficos en uno.

[0235]GTP-U (capa): Tal capa también se denomina protocolo de túnel de usuario en español.

[0236]]P: acrónimo de «Internet Protocol» por «protocolo de internet».

[0237]L1: acrónimo de «Layer L1» por «capa L1». La capa 1 se denomina también capa física en la pila de protocolos OSI.

[0238]L2: acrónimo de «Layer L2» por «capa L2». La capa 2 se denomina también capa de enlace de datos («data link») en la pila de protocolos OSI.

[0239]L2/L1 (capas): acrónimo de «Layer L2 over Layer L1» por «capa L2 sobre capa L1».

[0240]LTE: acrónimo de «Long Term Evolution» por «evolución a largo plazo».

[0241]MAC (capa): acrónimo de «Media Access Control» por «control de acceso a los medios». Esta capa es una capa de nivel 2. Más precisamente, es una subcapa (parte) de la capa 2.

[0242]La subcapa MAC permite el acceso y la adaptación al soporte de transmisión gracias a las funciones siguientes: el mecanismo de acceso aleatorio en el enlace ascendente; la corrección de errores por retransmisión HARQ durante la recepción de un acuse de recibo HARQ negativo; las asignaciones dinámicas y semiestáticas de recursos de radio (scheduling); el mantenimiento de la sincronización en el enlace ascendente y la priorización de los flujos en el enlace ascendente.

[0243]La función de programación se basa en las mediciones realizadas por la capa física, mientras que el mecanismo HARQ está acoplado con la codificación del canal. Por lo tanto, estas funciones están estrechamente vinculadas a la capa física y están optimizadas para este interfuncionamiento.

[0244]MME: acrónimo de «Mobility Management Entity» por «entidad de gestión móvil»; entidad LTE que gestiona la configuración y la movilidad. MME designa una entidad de control de la arquitectura de la red LTE.

[0245]Multi-hop: configuración con multisaltos, es decir, que afecta a varios relés.

[0246]Nivel de una capa: colocación de una capa con respecto a la pila de protocolos estándar OSI o, cuando sea aplicable, con respecto a las pilas de protocolos del plano de control o del plano de usuario descritas en la norma 3GPP.

[0247]Para la capa de nivel 1, véase la definición de capa PHY.

[0248]La capa 2 está compuesta por tres subcapas (de arriba a abajo): PDCP, RLC y MAC. Estas subcapas intervienen para la transferencia de datos, tanto desde el plano de usuario como desde el plano de control. Solo la subcapa PDCP está diseñada para tratar de modo diferente los datos de estos dos planos. Para RLC y MAC, es la configuración la que determina las posibles diferencias de procesamiento a aplicar a los flujos.

[0249]NAS (capa): acrónimo de «Non Access Stratum» por «estrato de no acceso». Tal capa hace posible la comunicación entre el terminal UE y la entidad MME en el plano de control. Esta capa es una capa de nivel 3.

[0250]PDCP (capa): acrónimo de «Packet Data Convergence Protocol» por «protocolo de convergencia de paquete de datos». Esta capa es una capa de nivel 2. Más precisamente, es una subcapa (parte) de la capa 2.

[0251]La subcapa PDCP asegura las funciones de seguridad y de transferencia de datos: compresión de encabezado (plano de usuario únicamente); cifrado de datos y de la señalización RRC (plano de control únicamente); protección de la integridad de la señalización RRC (plano de control únicamente); detección y supresión de duplicados (unidad de datos PDCP recibidos dos veces) y recuperación en secuencia de paquetes.

[0252]El tamaño del encabezado SDU PDCP en un plano de usuario se reduce con la ayuda de un mecanismo de compresión RoHC (compresión de encabezado robusto (ItalicRobust Header CompressionItalic)). Esta función tiene como objetivo mejorar la eficiencia espectral de los servicios conversacionales como la voz sobre IP (VoIP), que forma paquetes pequeños (pero con encabezados lo suficientemente grandes con respecto a la información útil a transmitir). No obstante, se definen varios perfiles de compresión para adaptar su utilización a diferentes usos (TCP/IP, UDP/IP, RTP/UDP/IP, ..). El eNodoB elige el perfil de compresión según las capacidades del UE (perfiles aceptados) y el tipo de servicio utilizado. La compresión de encabezado solo puede aplicarse a los SDU PDCP del plano de usuario.

[0253]Las funciones de cifrado y de protección de la integridad se refieren al plano de control (cifrado e integridad) y al plano de usuario (cifrado). Finalmente, se implementan también las funciones de detección de duplicados y de recuperación en secuencia para el plano de control y el plano de usuario. Son particularmente útiles durante un traspaso entre dos celdas LTE, durante el cual PDU PDCP se pueden recibir dos veces (envío a través de la celda fuente y la celda objetivo) y/o fuera de servicio (PDU N que se recibe antes que PDU N-1).

[0254]Por lo tanto, la subcapa PDCP se solicita para el transporte de señalización y datos de usuario. Además, las PDU PDCP de control, que son creadas por la capa PDCP y no por las capas superiores, se someten a un procesamiento específico (sin cifrado ni protección de integridad) y no están asociadas con las SDU PDCP. Un ejemplo es la PDU de informe de estado.

[0255]PDU: acrónimo de «Protocol Data Unit» por «unidad de protocolo de datos».

[0256]P-GW: acrónimo también denotado como «PDN-GateWay» que se refiere al término inglés «Packet Data Network GateWay» por «pasarela de la red de datos».

[0257]PHY (capa): acrónimo de «Physical Layer» por «capa física». Este nombre es el nombre alternativo de la capa de nivel 1.

[0258]La capa física o capa 1, también llamada Capa 1 (L1) o capa PHY, representa la capa física. Su función es garantizar la transmisión de datos en una forma capaz de propagarse por el aire y resistir las diversas perturbaciones inherentes al canal de radio móvil. Desde un punto de vista funcional, la capa física ofrece un servicio de transporte a través de la interfaz aérea a la capa MAC. La capa física realiza las funciones siguientes para la transmisión de datos: la codificación de canal, que protege los bits de información contra los errores de transmisión, introduciendo redundancias en la secuencia de bits transmitidos; la modulación, que asocia los bits para transmitir a símbolos de modulación capaces de imprimir una onda electromagnética; los tratamientos espaciales, que precodifican los símbolos de modulación para transmitirlos a varias antenas (por ejemplo para proporcionar una dirección a la señal emitida) y la modulación multiportadora.

[0259]Las operaciones inversas las realiza la capa física en la recepción, así como las operaciones de procesamiento para combatir la interferencia (por ejemplo, la ecualización). Por otra parte, la capa física asegura funciones que no implican transmisión de datos, pero que son necesarias para su funcionamiento, así como para ciertas funciones de la capa MAC: las mediciones de radio, para estimar el canal de transmisión, la calidad de la señal de la celda de servicio o los niveles de potencia recibidos de otra celda, o de otro sistema de radio; la sincronización, para adquirir y mantener la sincronización en el tiempo en la frecuencia con la portadora del emisor; la detección de celda, para detectar la presencia de celdas y conectarse a ellas, al encender el UE o para preparar un handover y la señalización de informaciones de control entre el eNodoB y el UE.

[0260]Punto de acceso: este término designa la combinación o el conjunto entre el emisor/receptor de radio (o varios) y la máquina virtual (o varias) que desempeñan el papel de una estación base o un punto de acceso a la red para uno o varios terminales móviles. Este término corresponde a otra terminología utilizada comúnmente de «punto de acceso a la red».

[0261]Rel. f : acrónimo de «Relaying function» por «función de retransmisión». Esta función especial de retransmisión o de enrutamiento se añade (en principio) en un UER con la función de retransmitir las mediciones efectuadas por el UE (o UER) en la interfaz UE-UER o con otros UE en la interfaz UE-UE. Esta función es aplicable a situaciones en las que, por ejemplo, no hay protocolos RRC UE y NAS UE directamente entre el UE y la VM a través de un UER, y/o si RRC R y NAS R no transfieren/encapsulan las medidas RRC EU y NAS EU. Para el enlace ascendente, el segundo papel de esta función de retransmisión es filtrar los paquetes y dirigirlos a la capa de aplicación UER o a la red. De manera similar, para el enlace descendente, la función Rel. f («Relaying function») se añade en un UER para filtrar los paquetes y dirigirlos hacia la capa de aplicación UER o hacia otro U<e>.

[0262]RAN: acrónimo de «Radio Access Network» por «red de acceso por radio».

[0263]RLC (capa): acrónimo de «Radio Link Control» por «control de enlace por radio». Cabe apreciar que la capa RLC por sí sola, sin una capa MAC, no se puede implementar. Esta capa es una capa de nivel 2. Más precisamente, es una subcapa (parte) de la capa 2.

[0264]La subcapa RLC (Radio Link Protocol) asegura las funciones de control del enlace de datos asignados a la capa 2 del modelo OSI (Data Link Control): detección y retransmisión de los PDU ausentes (en modo reconocido) que permiten la recuperación en caso de error; recolocación en secuencia de los PDU para asegurar la programación de los SDU en la capa superior (PDCP); por ejemplo, el desorden en la recepción de los paquetes puede ser el resultado de varios procesos HARQ (por ejemplo, con el paquete N recibido antes del paquete N-1) y utilización de ventanas de emisión y de recepción para optimizar la transmisión de datos.

[0265]A diferencia del UMTS, la capa RLC en LTE no realiza control de flujo: el UE y el eNodoB son capaces de procesar tramas RLC siempre que lleguen a la ventana de recepción RLC.

[0266]RoHC: acrónimo de «Robust Header Compression» por «compresión de encabezado robusto»; esta técnica es un procedimiento para comprimir los encabezados de paquetes de tipo IP.

[0267]RRC (capa): acrónimo de «Radio Resource Control» por «control de recurso de radio»; tal capa permite, en el plano de control, comunicar informaciones de control y de configuración entre el terminal UE y la entidad eNodoB. Esta capa es una capa de nivel 3. Más precisamente, es una subcapa (parte) de la capa 3.

[0268]La capa RRC se utiliza para controlar la interfaz de radio. De hecho, se puede ver que la capa RRC está conectada a las otras cuatro capas, a través de puntos de acceso de control: RRC es responsable de la configuración y control de las capas de nivel 1 (PHY) y 2 (MAC, RLC y PDCP).

[0269]Esta función es posible gracias al intercambio de información entre las entidades RRC remotas, ubicadas dentro del UE y el eNodoB, siguiendo los procedimientos del protocolo RRC. Los mensajes RRC son procesados por las capas PDCP, RLC, MAC y PHY antes de transmitirse a través de la interfaz de radio, a continuación se reconstituyen, se verifican y se interpretan por la entidad RRC remota. La señalización RRC requiere así un cierto tiempo de tratamiento por el UE y consume muchos recursos de radio, y además no puede utilizarse con demasiada frecuencia. Para la capa física, esto se denomina configuración semiestática cuando se realiza por la RRC.

[0270]Un UE presente en una celda LTE está en modo espera (o RRC_IDLE) cuando no tiene una conexión RRC activa con el eNodoB. En este caso, decodifica regularmente la información del sistema transmitida por el eNodoB en la celda, así como los mensajes de notificación (paginación). En este estado, el UE controla de forma autónoma su movilidad. Cuando ha establecido una conexión RRC, está en modo conectado, también llamado RRC_CONNECTED en la interfaz de radio. RRC debe así gestionar la conexión activa, la movilidad del UE, la transferencia de la señalización NAS o Non Access Stratum, la seguridad AS o Access Stratum (gestión de las claves de seguridad) así como los soportes de radio activados para transportar los datos de servicio y o la señalización (RRC y NAS).

[0271]RRC asegura así las funciones siguientes: la difusión y la decodificación de informaciones de sistema de niveles AS y NAS en la celda, para todos los UE en modo espera presentes en ella, proporcionando en particular los parámetros de acceso a la celda, de medición y de reselección en modo espera; el envío y la recepción de paging, para el establecimiento de llamada destinado a un UE en modo espera, para informar a los U<e>de la celda de que las informaciones de sistema han sido modificadas o para avisarles en caso de fuerza mayor (por ejemplo, en caso de temblor de tierra o de tsunami); la gestión de la conexión RRC (establecimiento, reconfiguración y liberación); el control de los radio bearers asociados a servicios o a la señalización; el control de las mediciones del UE y su subida al eNodoB en modo conectado; la movilidad en modo conectado; el control de la movilidad en modo espera (selección y reselección de celda) y la transmisión de la señalización de las capas superiores NAS.

[0272]La información del sistema transmitida en la celda se divide en varios bloques, cada uno de los cuales contiene un tipo definido de información (por ejemplo, información general sobre la celda del servidor, sobre su configuración de radio, sobre las celdas vecinas LTE, UMTS, GSM). Estos bloques se denominan SIB (por bloque de información del sistema (System Information Block)), conteniendo cada SIB un tipo de información definida en las especificaciones. El MIB (bloque de información maestro (Master Information Block)) desempeña una función particular ya que proporciona a los UE los parámetros esenciales que les permiten determinar la estructura y periodicidad de la información del sistema. Así debe repetirse frecuentemente (cada 10 ms), para que un UE que llega a la celda pueda obtenerlo rápidamente.

[0273]Además, su periodo de actualización es asimismo reducido (40 ms), para que esté indicado un posible cambio en la estructura de las Informaciones de sistema en los UE en un plazo breve.

[0274]RRH [acrónimo de «Remote Radio Head» por «cabeza de radio a distancia»]: El emisor/receptor de radio se designa también por el término «Light eNodoB» o por el acrónimo TP que remite a «Transmission Point». La diferencia fundamental es que un RRH implementa la parte inferior de la pila de protocolos, por ejemplo, RF y/o PHY, y que el TP también implementa un conjunto más completo de la pila de protocolos, por ejemplo, también el protocolo MAC y/o RLC.

[0275]RF: acrónimo de «Radio Frequency» por «radiofrecuencia».

[0276]RSRP: acrónimo de «Reference Signal Received Power» que significa «potencia recibida de la señal de referencia» o «potencia de la señal de referencia en la recepción». Esto corresponde a una medida de la potencia de la señal recibida en LTE.

[0277]RSRQ: acrónimo de «Reference Signal Received Quality» que significa «calidad recibida de la señal de referencia» o «calidad de la señal de referencia a la recepción». Esto corresponde a una medición de la calidad del enlace de radio en LTE.

[0278]S1-AP (capa): acrónimo de «S1 Application Protocol» por protocolo de aplicación S1

[0279]SCTP (capa): acrónimo de «Stream control transmission protocol» por «protocolo de transmisión relativo al control de flujo».

[0280]Servidor de aplicación (acrónimo AS para la terminología inglesa de «Application Server»): servidor distante (fuera de una red móvil) que está, por ejemplo, en una red de tipo IP e implementa una aplicación en IP.

[0281]single-hop: configuración con un único salto, es decir, una configuración en la que se utiliza un solo relé.

[0282]S-GW: acrónimo de «Serving gateway» por «pasarela de servicio». Este término designa una entidad que constituye una pasarela regional conectada a la entidad P-GW. La entidad S-GW recopila los datos procedentes de los terminales a través de las estaciones base a enviar a la entidad P-GW, y viceversa.

[0283]UE: acrónimo de «user equipment» por «equipo de usuario»; las letras «UE» designan, en el contexto de la presente invención, por ejemplo, un equipo que está montado en un soporte móvil o en inglés «User Equipment» y que representa también, por abuso de lenguaje, al equipo móvil o al usuario móvil. Por lo tanto, el terminal UE se refiere a diversos equipos que pueden comunicarse entre sí a través de la red, por ejemplo, teléfonos móviles u ordenadores portátiles. Además, se pueden utilizar otros términos para describir un equipo de usuario tales como estación móvil, equipo o terminal portátil, estación de abonado, terminal remoto, terminal inalámbrico o dispositivo de usuario. De manera general, el término «UE» hace referencia a un equipo inalámbrico con acceso inalámbrico a una entidad eNodoB, ya sea el terminal UE un dispositivo móvil (teléfono o teléfono inteligente) o un dispositivo inmóvil (como un autómata de venta o un ordenador de sobremesa).

[0284]UE relé o UER: equipo portátil que desempeña el papel de relé para extender la cobertura más allá del alcance del eNodoB de establecimiento. El UE relé se denomina a veces relé.

[0285]VM: acrónimo de «Virtual Machine» por «máquina virtual».

[0286]XXXX UER (capa) o XXXX R: capa XXXX (XXXX designa cualquier capa anterior) implementada por el relé UER. El término capa XXXX específica de relé también se utiliza para designar dicha capa. De manera similar, a veces se usa el término capa XXXX R.

[0287]XXXX UE (capa): capa XXXX (XXXX que designa cualquier capa anterior) implementada por un terminal. El término capa XXXX específica de terminal también se utiliza para designar dicha capa. En tal contexto, la capa XXXX puede ser una capa controlada o en relación con un UER (entre un UE y un UER) O una capa controlada o en relación con un punto de acceso (entre un UE y un eNB) atravesando uno o más UER. En otras palabras, puede haber un protocolo que se establece entre un UE y distintas entidades, relés o punto de acceso, ya sea o no a través de otro relé.

[0288](XXXX): utilización opcional de una capa XXXX.

Claims (5)

REIVINDICACIONES

1. Procedimiento de determinación de una configuración de al menos un relé entre un punto de acceso y los terminales en una arquitectura en red que incluye una pluralidad de entidades entre ellos al menos un punto de acceso, al menos un relé, un controlador y terminales,

una configuración de relés que determina las capas implementadas por las entidades, incluyendo el procedimiento: - una etapa de generación de un primer gráfico de red, siendo un gráfico de red un gráfico que asocia una magnitud física asociada a cada intercambio de datos entre dos entidades entre el punto de acceso, el relé y los terminales,

estando el procedimientocaracterizado porqueel primer gráfico de red es un gráfico de conectividad, siendo el gráfico de conectividad un gráfico que muestra las posibles conexiones entre las diferentes entidades y que contiene también valores de relación señal/ruido o de relación señal/ruido más interferencia, yporqueel procedimiento incluye las etapas de:

- elección de la configuración de relés basándose en el primer gráfico de red, comprendiendo las configuraciones una configuración de un solo salto, una configuración de varios saltos, una configuración de multidifusión, una configuración sin relés,

- generación de un segundo gráfico de red, siendo el segundo gráfico de red un gráfico de medición de la calidad del enlace en cada conexión,

- para una configuración de relés en la que al menos dos entidades son capaces de emitir hacia un terminal, determinación de si una conmutación hacia otra entidad que emite hacia el terminal o que recibe desde el terminal es conveniente para el terminal considerado, estando la determinación implantada basándose en el segundo gráfico de red, y

- cuando se determina para el terminal considerado, que una conmutación es conveniente, el procedimiento comprende:

- la implantación de la conmutación hacia la otra entidad,

- la generación de un tercer gráfico de red, siendo el tercer gráfico de red un gráfico de latencia, - una nueva implantación de las etapas de generación, de elección y determinación,

- cuando se determina para el terminal considerado, que una conmutación hacia otra entidad no es conveniente, el procedimiento comprende una prueba del conjunto de las configuraciones posibles para el terminal para determinar si es posible una configuración que tenga un solo salto y seleccionarla como configuración en su caso.

2. Procedimiento según la reivindicación 1 en el que un gráfico de red representa una visión sintética y dinámica de los parámetros y de los enlaces de la red relacionados bien con los rendimientos actuales de la red o bien con las exigencias que se desean alcanzar, en relación con los intercambios de información entre dos entidades entre el punto de acceso, el relé y los terminales.

3. Procedimiento según la reivindicación 1 o 2, en el que durante la elección de la configuración, se determina al menos una de las tres propiedades anteriores:

- una primera propiedad relativa a qué capas se van a implementar,

- una segunda propiedad relativa a qué entidad implementa en cada capa, y

- una tercera propiedad relativa a cómo se configuran las capas.

4. Procedimiento según cualquiera de las reivindicaciones 1 a 3, en el que durante la elección de la configuración, se determina al menos una de las propiedades siguientes:

- qué entidad implementa la capa RRC,

- qué entidad implementa la capa NAS, y

- qué entidad implementa la capa PDCP.

5. Procedimiento según cualquiera de las reivindicaciones 1 a 4, en el que el primer gráfico de red es actualizado para cada nueva entidad, especialmente cada nuevo terminal y/o relé que entra en la arquitectura.