ES2647445T3 - Transferencia de mensajes - Google Patents

Transferencia de mensajes Download PDF

Info

Publication number
ES2647445T3
ES2647445T3 ES12360033.0T ES12360033T ES2647445T3 ES 2647445 T3 ES2647445 T3 ES 2647445T3 ES 12360033 T ES12360033 T ES 12360033T ES 2647445 T3 ES2647445 T3 ES 2647445T3
Authority
ES
Spain
Prior art keywords
base station
destination
application protocol
destination base
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES12360033.0T
Other languages
English (en)
Inventor
Philippe Godin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alcatel Lucent SAS
Original Assignee
Alcatel Lucent SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alcatel Lucent SAS filed Critical Alcatel Lucent SAS
Application granted granted Critical
Publication of ES2647445T3 publication Critical patent/ES2647445T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/20—Interfaces between hierarchically similar devices between access points
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/14—Backbone network devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/04—Reselecting a cell layer in multi-layered cells

Abstract

Un procedimiento realizado por un nodo (40) proxy para transferir mensajes entre las estaciones (20, 30) base de una red de telecomunicaciones inalámbrica, comprendiendo dicho procedimiento las etapas de: recibir un mensaje de Protocolo de Aplicación X2 dentro de un paquete IP de interfaz X2 entrante sobre una interfaz X2 desde una estación base origen; extraer, desde dicho mensaje de Protocolo de Aplicación X2, información de identidad de estación base de destino que identifica una estación base de destino; enrutar dicho mensaje de Protocolo de Aplicación X2 a dicha estación base, portándose dicho mensaje de Protocolo de Aplicación X2 dentro de un paquete IP de interfaz X2 saliente que tiene una dirección IP de destino derivada de dicha información de identidad de estación base de destino; y mantener una asociación de Protocolo de Aplicación X2 directa entre dicha estación base de origen y dicha estación base de destino, portándose dicha asociación de Protocolo de Aplicación X2 sobre dos asociaciones SCTP, una desde dicha estación base de origen hasta dicho nodo proxy y una desde dicho nodo proxy hasta dicha estación base de destino.

Description

5
10
15
20
25
30
35
40
45
50
DESCRIPCION
Transferencia de mensajes Campo de la invención
La presente invención se refiere a un procedimiento para transferir mensajes entre estaciones base de una red de telecomunicaciones inalámbrica, un nodo proxy, un procedimiento para transmitir mensajes desde una estación base, una estación base y productos de programas informáticos.
Antecedentes
Transmitir mensajes entre estaciones base de una red de telecomunicaciones inalámbricas se conoce. Por ejemplo, en redes de evolución a largo plazo (LTE), los mensajes se envían directamente entre estaciones base que usan una interfaz X2. Un procedimiento típico para establecer la interfaz X2 es, primero, se detecta una celda, normalmente por un equipo de usuario y, se informa a una estación base de servicio en un informe de usuario. La estación base de servicio pasa entonces el identificador de celda a la red, que devuelve una dirección IP de una estación base objetivo que soporta la celda detectada. La estación base de servicio entonces establece una conexión de Protocolo de Transmisión de Control de Flujo (SCTP) o "Asociación" entre las dos estaciones base. La interfaz X2 se establece, entonces, entre la estación base origen y destino a través de esta conexión SCTP y permite que los mensajes se transfieran entre las dos estaciones base.
Además de las macroceldas proporcionadas por las macroestaciones base, se pueden proporcionar otros tipos de celdas y estaciones base dentro de la red de telecomunicaciones inalámbrica. Tal ejemplo de tal estación base es una estación base de celda pequeña. Tal estación base de celda pequeña normalmente proporciona cobertura usando una celda pequeña que tiene un intervalo relativamente limitado normalmente dentro del área de cobertura de una macrocelda. La potencia de transmisión de una estación base de celda pequeña es relativamente baja y, por lo tanto, la celda pequeña proporciona un área de cobertura pequeña que cubre, por ejemplo, una oficina o un hogar.
Tales celdas pequeñas típicamente se proporcionan cuando la cobertura de comunicaciones proporcionadas por la macrocelda es pobre o cuando un usuario desea usar un enlace de comunicaciones alternativo proporcionado localmente, por la estación base de celda pequeña, para comunicarse con la red central.
La implementación de tales celdas pequeñas puede tener consecuencias inesperadas, particularmente en relación con la escalabilidad, cuando transmiten mensajes entre estaciones base.
3GPP TSG-RAN WG3 #75bis R3-120852, 3GPP TSG-RAN WG3 #75bis R3-120736 y 3GTPP TSG-RAN WG3 #75 R3-120321 desvela cada uno un concepto de concentrador X2 SCTP.
El concentrador asigna una señalización en el flujo SCTP apropiado. El concentrador lee la dirección desde el fragmento SCTP INIT en el mensaje SCTP y al mensaje X2 se asigna entonces a un flujo SCTP.
3GPP TSG-RAN WG3 #75 R3-120437 y 3GPP TSG-RAN WG3 #75bis R3-120607 desvelan una disposición de proxy X2. Una asociación SCTP se configura entre las estaciones base y una puerta de enlace. El mensaje de solicitud de configuración X2 recibido por la puerta de enlace finaliza localmente y se genera un nuevo mensaje de solicitud de establecimiento X2 hacia eNB1.
Por consiguiente, se desea proporcionar una técnica mejorada para transmitir mensajes entre estaciones base. Sumario
De acuerdo con un primer aspecto, se proporciona un procedimiento como se reivindica en la reivindicación 1.
El primer aspecto reconoce que un problema con la proliferación de celdas y, particularmente celdas pequeñas, dentro de la red es que el número de enlaces directos entre las estaciones base aumenta. Esto se debe a que típicamente cada estación base configura y mantiene un enlace dedicado entre ella y cada una de sus estaciones base vecinas. Típicamente, una única conexión SCTP se realiza entre una estación base y un vecino sobre el que se establece la interfaz X2. A medida que el número de vecinos aumenta, también lo hace el número de conexiones SCTP separadas y las interfaces x2 superpuestas. Esto conduce a un drenaje de recursos dentro de la estación base debido a la necesidad de mantener cada una de estas condiciones y los estándares existentes no contemplaron que tal gran número de conexiones podría ser necesario. Aunque se han propuesto diferentes técnicas para lograr abordar este problema, el primer aspecto reconoce que cada uno tiene sus propios inconvenientes, normalmente debido a ser incoherentes con los protocolos definidos por estándares de terceros debido a la complejidad en el procesamiento requerido para implementar esas técnicas.
En particular, se han presentado dos tipos de proxy hasta ahora en los estándares 3GPP para resolver este problema. El primer tipo de proxy es similar al definido en la versión 10 para manejar Nodos de Retransmisión. Este tipo de proxy oculta la celda pequeña o las estaciones base domésticas (HeNB) desde la macroestación base para que la macro eNB vea el vínculo proxy como una macro eNB vecina que presenta muchas celdas (que están en las
5
10
15
20
25
30
35
40
45
50
55
60
HeNB). En este primer tipo de proxy, todos los mensajes X2AP finalizan, por lo tanto, en el proxy. La solución presenta alta complejidad para el proxy porque finaliza todos los mensajes X2AP, los interpreta y mantiene los contextos X2 correspondientes en dos lados, también tiene que mantener la memoria del estado de la relación vecina entre la macro eNB y las HeNB que pueden actualizarse con frecuencia y, finalmente, el manejo simultáneo de tanto las conexiones directas como la x2 mediante proxy por la macro eNB introduce nueva complejidad. Esta primera solución también introduce cambios en el comportamiento de la macro eNB y HeNB actuales. El segundo tipo de proxy se ha introducido recientemente como un tipo de concentrador SCTP. En un extremo opuesto de la primera solución mencionada anteriormente, este concentrador tiene como objetivo no terminar todos los protocolos X2AP en el proxy. Por lo tanto, depende totalmente en una solución de asignación de flujo SCTP mediante la cual, la macro eNB obtiene una (o varias) asociación(es) SCTP al proxy o sobre esta asociación SCTP usa un flujo (o par de flujos SCTP) para dirigir una HeNB vecina particular. En el lado de la HeNB, una HeNB todavía se está dirigiendo por una asociación SCTP según el modelo 8/9/10 de liberación. Esta segunda solución presenta deficiencias graves al nivel de transporte. También, este tipo de concentrador SCTP no existe en el mercado actualmente y debería desarrollarse por completo. También es incompatible con una pila SCTP compatible con RFC según RFC4960. Cuando la macro eNB ya ha configurado su asociación SCTP al proxy y descubre una nueva HeNB vecina, es indefinida o es técnicamente cuestionable cómo podría solicitar el proxi accionar la configuración de la asociación SCTP X2 hacia la HeNB sin que el proxy finalice el protocolo X2AP. En la otra dirección, cuando la HeNB descubre una eNB es indefinida o técnicamente cuestionable cómo el proxy puede añadir un nuevo flujo SCTP sobre la asociación SCTP entre el proxi y la macro eNB y cómo la macro eNB puede identificar la asignación entre el flujo SCTP y la ID HeNB. La gestión global del flujo SCTP sigue siendo un problema real en esta solución considerando también que se necesita un flujo SCTP muy dinámico basándose en el descubrimiento/eliminación de las relaciones vecinas HeNB particularmente según estándares SCTP actuales contemplan que el intervalo de flujos que se usará solo es negociable en la configuración de iniciación SCTP.
Por consiguiente, se proporciona un procedimiento para transferir mensajes entre estaciones base de una red de telecomunicaciones inalámbrica. El procedimiento puede comprender la etapa de recibir un mensaje de protocolo de aplicación X2 entrante dentro de un paquete IP de interfaz X2 sobre una conexión SCTP desde una estación base de origen. El procedimiento puede comprender también la etapa de extracción, desde el paquete IP de interfaz X2 entrante, información de identidad de estación base de destino que identifica una estación base de destino. El procedimiento también puede comprender la etapa de enrutar o transferir el mensaje de protocolo de aplicación X2 a la estación base de destino. El mensaje de aplicación de protocolo X2 puede portarse dentro de un paquete IP de interfaz X2 saliente que tiene una dirección IP de destino que se deriva desde la información de identidad de estación base de destino.
Este enfoque usa un mensaje de protocolo de aplicación X2 modificado que incluye la información de identidad de estación base de destino y que se envuelve dentro de un paquete IP de interfaz X2. Esto permite que el mensaje modificado se reciba por un proxy y la dirección IP de la estación base de destino fácilmente derivado por lo que el mensaje puede retransmitirse sobre una estación base de destino requiriéndose procesamiento mínimo por el proceso. También, la misma conexión SCTP única entre la estación base de origen y el proxy puede usarse para portar los mensajes de protocolo de aplicación X2 al proxy para cualquier número de estaciones base de destino. Esto simplifica significativamente el procesamiento y los recursos requeridos dentro de la estación base de origen y el proxy. Además, el proxy puede utilizar la misma conexión SCTP única con la estación base de destino para transferir mensajes con la estación base de destino para cualquier número de macroestaciones base diferentes. De nuevo, esto simplifica el procesamiento y los recursos requeridos en la estación base de destino y el proxy. Además, la extracción de la información de identidad de estación base de destino y la generación del mensaje saliente puede realizarse aun eficazmente dentro de la capa de protocolo X2 que reduce significativamente el procesamiento y los recursos requeridos desde el proxy, que puede permanecer eficazmente sin estado y puede usar una pila SCTP compatible con RFC. El procedimiento permite una asociación X2AP directa para permanecer definida de extremo a extremo entre la estación base de origen y de destino finalizando el Protocolo de Aplicación X2 completo en el proxi que hace que el proxy sea simple y sin corresponder a los contextos X2 de estado correspondientes. Todo esto mejor la flexibilidad, fiabilidad y escalabilidad para establecer y mantener conexiones entre las estaciones base comparado con las técnicas existentes.
En una forma de realización, la etapa de recepción comprende recibir el mensaje de Protocolo de Aplicación X2 entrante en un nodo proxy que tiene una dirección IP incluida dentro del paquete IP de interfaz X2 que porta el mensaje de Protocolo de Aplicación X2 entrante. De este modo, el mensaje de protocolo de aplicación X2 se envía por la estación base de origen a la dirección IP del proxy.
En una forma de realización, la etapa de extracción comprende extraer la dirección IP de destino desde la información de identidad de estación base de destino y la etapa de enrutamiento o transferencia comprende enrutar el mensaje de Protocolo de Aplicación X2 portado dentro del paquete IP de interfaz X2 saliente que tiene la dirección IP de destino para la transmisión a la estación base de destino. De este modo, el mensaje de protocolo de aplicación X2 se envía por el proxy a la dirección IP de la estación base de destino.
En una forma de realización, el procedimiento comprende la etapa de mantenimiento de una tabla de búsqueda que combina la información de identidad de estación base de destino con direcciones IP de estación base de destino correspondientes, la etapa de enrutamiento o transferencia comprende identificar la dirección IP de destino desde la
5
10
15
20
25
30
35
40
45
50
tabla de búsqueda usando la información de identidad de estación base de destino y enrutar o transferir el mensaje de Protocolo de Aplicación X2 portado dentro del paquete IP de interfaz X2 saliente que tiene la dirección IP de destino para transmisión a la estación base de destino.
En una forma de realización, el procedimiento comprende la etapa de consultar una tabla de búsqueda externa para obtener una dirección IP de estación base de destino en respuesta para proporcionar la información de identidad de estación base de destino.
En una forma de realización, el procedimiento comprende la etapa de recibir la dirección IP de estación base de destino para inclusión en la tabla de búsqueda durante la transferencia de mensajes de interfaz S1 con la estación base de destino.
En una forma de realización, la etapa de extracción comprende decodificar el paquete IP de interfaz X2 entrante que contiene el mensaje de Protocolo de Aplicación X2 de acuerdo con un protocolo de capa ligera para extraer la información de identidad de estación base de destino.
En una forma de realización, la etapa de extracción comprende decodificar el paquete IP de interfaz X2 entrante que contiene el mensaje de Protocolo de Aplicación X2 de acuerdo con un protocolo de capa ligera para extraer la dirección IP de destino.
El procedimiento comprende la etapa de mantener una asociación de Protocolo de Aplicación X2 directa entre la estación base de origen y la estación base de destino, portándose la asociación de Protocolo de Aplicación X2 sobre dos asociaciones SCTP, una desde la estación base de origen hasta el nodo proxy y una desde el nodo proxy hasta la estación base de destino.
En una forma de realización, el procedimiento comprende la etapa de mantener una asociación SCTP con la estación base de origen y una asociación SCTP separada con la estación base de destino.
En una forma de realización, el procedimiento comprende la etapa de establecer una asociación SCTP con la estación base de destino al recibir el mensaje de interfaz X2AP entrante.
De acuerdo con un segundo aspecto, se proporciona un proxy como se reivindica en la reivindicación 7.
En una forma de realización, la lógica de recepción es operable para recibir el mensaje de Protocolo de Aplicación X2 entrante en un nodo proxy que tiene una dirección IP incluida dentro del paquete IP de interfaz X2 que porta el mensaje de Protocolo de Aplicación X2 entrante.
En una forma de realización, la lógica de extracción es operable para extraer la dirección IP de destino desde la información de identidad de estación base de destino y la lógica de enrutamiento es operable para enrutar el mensaje de Protocolo de Aplicación X2 portado dentro del paquete IP de interfaz X2 saliente que tiene la dirección IP de destino para la transmisión a la estación base de destino.
En una forma de realización, el proxy comprende una tabla de búsqueda que combina una información de identidad de estación base de destino con direcciones IP de estación base de destino correspondientes y en la que la lógica de enrutamiento es operable para identificar la dirección IP de destino desde la tabla de búsqueda usando la información de identidad de estación base de destino y para generar el mensaje de Protocolo de Aplicación X2 portado dentro del paquete IP de interfaz X2 saliente que tiene la dirección IP de destino para transmisión a la estación de base de destino.
En una forma de realización, la lógica de recepción es operable para recibir la dirección IP de estación base de destino para inclusión en la tabla de búsqueda durante la transferencia de los mensajes de interfaz S1 con la estación base de destino.
En una forma de realización, la lógica de extracción es operable para decodificar el paquete IP de interfaz X2 entrante que contiene el mensaje de Protocolo de Aplicación X2 de acuerdo con un protocolo de capa ligera para extraer la información de identidad de estación base de destino.
En una forma de realización, la lógica de extracción es operable para decodificar el paquete IP de interfaz X2 entrante que contiene el mensaje de Protocolo de Aplicación X2 de acuerdo con un protocolo de capa ligera para extraer la dirección IP de destino.
El proxy comprende una lógica de interfaz operable para mantener una asociación de Protocolo de Aplicación X2 directa entre la estación base de origen y la estación base de destino, portándose la asociación de Protocolo de Aplicación X2 sobre dos asociaciones SCTp, una desde la estación base de origen hasta el nodo proxy y una desde el nodo proxy hasta la estación base de destino.
En una forma de realización, el proxy comprende una lógica de interfaz operable para mantener una asociación SCTP con la estación base de origen y una asociación SCTP separada con la estación base de destino.
5
10
15
20
25
30
35
40
45
50
55
En una forma de realización, la lógica de interfaz es operable para establecer una asociación SCTP con la estación base de destino al recibir el mensaje de interfaz X2AP entrante.
De acuerdo con un tercer aspecto, se proporciona un producto de programa informático operable, cuando se ejecuta en un ordenador, para realizar las etapas del procedimiento del primer aspecto.
Aspectos particulares y preferentes adicionales se establecen en las reivindicaciones independientes y dependientes adjuntas. Las características de las reivindicaciones dependientes pueden combinarse con características de las reivindicaciones independientes según sea apropiado y, en otras combinaciones diferentes a las explícitamente establecidas en las reivindicaciones.
Cuando una característica del aparato se describe como siendo operable para proporcionar una función, se apreciará que esto incluye una característica del aparato que proporciona esta función o que se adapta o configura para proporcionar la función.
Breve descripción de los dibujos
Las formas de realizaciones de la presente invención se describirán ahora adicionalmente, con referencia a los dibujos adjuntos, en los que:
la figura 1 proporciona una visión general de una técnica de proxy de acuerdo con una forma de realización;
la figura 2 muestra una Arquitectura Lógica con una función de proxy X2;
la figura 3 muestra una arquitectura de red lógica para un concentrador SCTP;
la figura 4 muestra una arquitectura de red lógica de acuerdo con una forma de realización;
la figura 5 ilustra un procedimiento de configuración X2 básico de acuerdo con una forma de realización; y
la figura 6 ilustra un procedimiento de traspaso de acuerdo con una forma de realización;
Descripción de las formas de realización
Visión general
Antes de tratar las formas de realización con mayor detalle, primero se proporciona una vista general. Tal y como se ha mencionado anteriormente, la implementación densa de estaciones base de celdas pequeñas puede conducir a un alto número de tales estaciones base de celdas pequeñas que se identifican como vecinas a una macroestación base (por ejemplo, puede haber varios cientos o, incluso miles de vecinos de celdas pequeñas). La interfaz X2 se usa para comunicación entre las estaciones base vecinas y el establecimiento y el mantenimiento de tal número de conexiones X2 puede devenir cuestionable para una macroestación base, en particular con respecto al establecimiento y mantenimiento de este número de asociaciones SCTP con cada uno de los vecinos.
Por consiguiente, se proporciona una técnica que usa un nuevo tipo de mensaje de Protocolo de Aplicación X2 (X2AP) que incluye un nuevo elemento de información denominado identificador de estación base de destino. Este nuevo tipo de mensaje X2AP puede ser o un mensaje X2AP modificado que incluye el nuevo elemento de información o bien, puede ser un paquete IP generado en respuesta a una capa de protocolo ligera entre la capa SCTP y la capa X2AP que incorpora el mensaje X2AP original dentro de la carga útil del mensaje generado por la capa de protocolo ligera y que añade el identificador de estación base de destino.
En cualquier caso, el mensaje X2AP modificado se transmite a un nodo de red designado por la red. El nodo de red se designa por la red usando la señalización S1. En particular, la red puede proporcionar la dirección IP de cualquier puerta de enlace de celda pequeña que exista que pueda proporcionar funcionalidad de enrutamiento, reenvío o proxy, como se describirá en mayor detalle a continuación o, puede proporcionar la dirección IP de otro nodo de red que proporcione esta funcionalidad (esta funcionalidad no debería estar presente en la puerta de enlace de celda pequeña o no debería estar presente ninguna puerta de enlace de celda pequeña). Como alternativa, la red puede proporcionar la dirección IP de la propia estación base de celda pequeña de destino de manera que las conexiones directas aún puedan también establecerse, si se requiere.
En este enfoque, cuando se usa algún tipo de proxy, ya sea que está en una puerta de enlace de celda pequeña o en cualquier otro lugar, este proxy se usa como un enrutador en el nivel X2AP para enrutar mensajes X2AP. A diferencia de otros enfoques, esto permite que la macroestación base continúe viendo y creando una asociación o conexión X2AP con estaciones base de celdas pequeñas y puede, por lo tanto, manejar las relaciones X2AP de una manera similar a la que existe actualmente. A diferencia de otros enfoques, no se requiere una asignación específica en los flujos SCTP designados proporcionados por la macroestación base para poder dirigir una estación base de celda pequeña. En su lugar, la estación base de celda pequeña se dirige al nivel X2AP por un identificador específico para permitir que el proxy realice el enrutamiento correcto. A diferencia de las soluciones que usan una asignación de flujo SCTP, en esta técnica, el proxy finaliza el protocolo X2AP, pero solo con fines de enrutamiento y, de este modo, permite una que asociación o conexión X2AP se mantenga de extremo a extremo entre la macroestación base y la estación base de celda pequeña. Por lo tanto, este enfoque hace que el proxy sea casi sin estado y mucho más simple que los enfoques que se basan en asignación de flujo e interrupción de una pila SCTP compatible con RFC. Este enfoque también hace que el proxy sea casi sin estado y mucho más simple que los
5
10
15
20
25
30
35
40
45
50
55
enfoques que, en su lugar, finalizan completamente todos los mensajes X2AP en el proxy, interpreta todos los mensajes X2AP, mantiene los contextos x2 correspondientes en ambos lados y, entonces, genera nuevos mensajes X2AP para la estación base de celda pequeña prevista. Las formas de realización usan simplemente los identificadores necesarios para dirigir los vecinos de la estación base de celda pequeña, junto con la capacidad de usar la dirección IP del proxy cuando se comunica con una estación base conectada a ese proxy. Este enfoque también es compatible con el uso de IPSEC para configurar túneles seguros para una puerta de enlace de celda pequeña al nivel de transporte, si fuera necesario.
La figura 1 proporciona una visión general de esta técnica de proxy. En este ejemplo, se ha identificado una celda de una estación 20 base de destino vecina, normalmente por medio de informes de equipo de usuario a la macroestación 30 de base proporcionada por el equipo de usuario (no mostrado). Usando la interfaz S1, la macroestación base informa del identificador de celda de la celda detectada y/o la estación 20 base de destino correspondiente a la red. De acuerdo con técnicas normales, la dirección IP de la estación base de destino se identifica por la red. Si se determina que la estación 20 base de destino debe comunicarse con el uso de un proxy 40, entonces la red devuelve la dirección IP del proxy 40 o, puede devolver la dirección IP del proxy 40, así como la dirección IP de la estación 20 base de destino usando señalización S1 o, puede devolver, usando señalización S1, la dirección IP del proxy 40, así como cualquier elemento información (enrutamiento) adicional que permite que el proxy derive la dirección IP de la estación 20 de base de destino. Si no se usa el proxy 40, entonces la dirección IP de la estación 20 base de destino se devuelve por la red.
La macroestación 30 base genera entonces una solicitud de configuración que incluye elementos de información de enrutamiento que se incorporarán en un mensaje de solicitud de configuración X2AP modificado. En este ejemplo, el mensaje de solicitud de configuración X2AP modificado incorpora un identificador de la estación 20 base de destino de manera que el proxy 40 es capaz de enrutar este mensaje de solicitud de configuración X2AP a esta estación 20 base de destino solamente decodificando el elemento de información adicional que incluye el identificador de estación base de destino. En particular, la macroestación 30 base transmite el mensaje de solicitud de configuración X2AP modificado a la dirección IP del proxy 40 proporcionada por la red.
Al recibir este mensaje de solicitud de configuración X2, el proxy 40 decodifica el elemento de información que contiene el identificador de estación base de destino y entonces deriva la dirección IP de la estación 20 base de destino ya sea directamente desde el identificador de estación base de destino o por referencia a una tabla de búsqueda que mantiene un enlace entre el identificador de estación base de destino y la dirección IP de estación base de destino.
El proxy 40 entonces reenvía el mensaje de solicitud de configuración X2AP a la dirección IP de la estación 20 base de destino. Como se puede ver, el procedimiento de configuración X2AP permanece de extremo a extremo entre la macroestación 30 base de origen y la estación 20 base de destino, a diferencia de los enfoques anteriores. Esto simplifica la operación del proxy 40 e introduce menos cambios al comportamiento nodal de las estaciones base involucradas.
En respuesta, la estación 20 base generará un mensaje de respuesta de configuración X2AP modificado similar que incluye un identificador de estación base de destino de la macroestación 30 base similar a la descrita anteriormente. Este mensaje de respuesta de configuración X2AP se envía a la dirección IP del proxy 40. De nuevo, el proxy 40 identifica la dirección IP de la macroestación 30 base de destino ya sea desde el propio identificador de estación base de destino o a través de una tabla de búsqueda mantenida por el proxy 40. El proxy 40 entonces reenvía el mensaje de respuesta de configuración X2AP a la dirección IP de la macroestación 30 base.
Se apreciará que el proxy 40 puede también volver a formatear los mensajes X2AP antes del reenvío con el fin de combinar los mensajes X2AP existentes con el fin de mantener la compatibilidad hacia atrás con el equipo heredado.
Se apreciará que los mensajes X2AP modificados pueden incorporar los identificadores de estación base de destino en una variedad de diferentes maneras. Un enfoque es añadir un elemento de información adicional al mensaje X2AP existente, que seguidamente se interpreta por el proxy 40. Otro enfoque es codificar el mensaje X2AP existente de acuerdo con un protocolo muy ligero entre la capa SCTP y a capa X2AP de una manera que incorpore el identificador de estación base de destino. Por ejemplo, el mensaje de Protocolo de Aplicación X2 puede portarse dentro de un paquete IP de interfaz X2 como una carga útil de la capa de protocolo ligera que incorpora el identificador de estación base de destino. De cualquier manera, el proxy 40 se configura realizar la operación de decodificación requerida con el fin de extraer el identificador de estación base de destino con el fin de poder derivar la dirección IP de la estación base de destino.
Usando este enfoque, el procedimiento X2 permanece de extremo a extremo entre la estación base de origen y la estación base de destino, a diferencia de algunos enfoques existentes. Esto simplifica el proxy 40 y también introduce menos cambios en el comportamiento nodal de las estaciones base.
Se apreciará que el proxy 40 puede o accionar una configuración de asociación SCTP con la estación base de destino si tal asociación no existe cuando se recibe el mensaje de solicitud de configuración X2AP desde la macroestación 30 base, o la estación 20 base de celda pequeña puede configurar esta asociación de antemano, una
10
15
20
25
30
35
40
45
vez que se ha informado de que se ha detectado por la macroestación 30 base por la red. Lo siguiente trata las formas de realización en mayor detalle.
Introducción
La introducción de un proxy X2 entre las macroestaciones base (eNB) y estaciones base de celdas pequeñas o domésticas (HeNB) han sido objeto de numerosos análisis durante los últimos encuentros 3GPP RAN3 y existen actualmente dos soluciones propuestas:
1. Adopción de una solución de Proxy X2 completa sobre la puerta de enlace de estación base de celda pequeña o de hogar (HeNB-GW) en referencia [1] y [2] similar a la implementada en la DeNB para retransmisión.
2. Adopción de una función de proxy Concentrador SCTP como se indica en la referencia [3]
Sin embargo, ambas propuestas tienen problemas que se resumirán a continuación. Por lo tanto, vale la pena buscar introducir una solución alternativa que podría no tener esos problemas. El presente documento describe tal alternativa.
Análisis
Visión general de las dos soluciones de proxy existentes
Una de las propuestas actuales para soportar una interfaz X2 entre eNB y HeNB propone la introducción de una función de proxy X2 en la HeNB-GW, ver referencia [1], que da como resultado la arquitectura de red mostrada en la figura 2 que muestra una Arquitectura Lógica EUTRAn HeNB con función de proxy X2 en HeNB-GW.
Una solución alternativa descrita en la referencia [3] propone la introducción de una función de proxy Concentrador SCTP como se muestra en la figura 3 que también muestra una arquitectura de red lógica para un concentrador SCTP.
Como se puede ver en las figuras 2 y 3, las dos soluciones no son complementarias ya que una requiere la implementación de una HeNB-GW, mientras que la otra no. Además, existe un número de problemas con ambas opciones como sigue:
La función de Proxy X2 completa tiene un número de inconvenientes que incluyen:
1. Obligar la implementación de una HeNB-GW independientemente o si la macro eNB se dimensiona suficientemente para poder soportar conexiones X2 directamente a HeNB.
2. Requerir la finalización de procedimientos X2 en la HeNB-GW, que se añade a la complejidad de la HeNB- GW, requiriendo eficazmente que se dimensione lo suficientemente para poder soportar conexiones X2 entre todas las HeNB que "gestiona" y todas las macro eNB que cualquiera de las HeNB podría necesitar para intercambiar mensajes X2.
3. Utilizando información desde ciertos mensajes X2 incorrectamente. Por ejemplo, en el mensaje de Solicitud de Configuración X2, el HeNB-GW tiene que retransmitir sobre la eNB/HeNB de origen que puebla los elementos de información vecinos (IE) de manera diferente, para que la HeNB-GW pueda usar esta información para determinar la eNB/HeNB de destino real. Puede argumentarse que esto está usando incorrectamente la información vecina, ya que la intención no es usar esto con fines de enrutamiento, sino para permitir que las eNB/HeNB de origen y destino para intercambiar información acerca de todas sus celdas vecinas.
4. Requerir el mantenimiento de una lista de celdas vecinas en la HeNB-GW, para poder determinar qué HeNB necesita actualizarse cuando cambia un NCL existente. Más precisamente, la HeNB-GW necesita mantener duplicados de todas las tablas de relaciones vecinas de las eNB y HeNB conectadas. Más generalmente, esto requiere almacenar contextos X2 para todas las estaciones base conectadas.
5. Requerirla implementación de un esquema de gestión ID X2AP en la HeNB-GW para permitir que se asignen y se rastreen nuevas ID X2AP contra ID HeNB y eNB.
6. Implementar nuevas y complejas lógicas cuando, por ejemplo, recibir una solicitud de configuración X2 debe conducir a la generación de un mensaje de Actualización de Configuración NB X2 completamente diferente.
La función de proxy Concentrador SCTP también tiene un número de inconvenientes que incluyen:
1. Depender del mantenimiento de asignaciones 1-2-1 entre flujos SCTP sobre cualquier lado del concentrador. Esto limita la flexibilidad, ya que, en teoría, la eNB de origen podría usar un flujo SCTP único para todo el "tráfico X2" hacia las HeNB anejados por el concentrador.
2. Implicar que en la creación de la asociación SCTP entre eNB y concentrador, que la eNB podría tener que solicitar suficientes flujos para todas las HeNB manejadas por el concentrador, que, en teoría, podría ser el máximo posible, es decir, 2**16 para cada asociación, incluso si la eNB solo necesita comunicarse con unas cuantas HeNB. Esto significa que muchos flujos se manejan potencialmente por el concentrador.
5
10
15
20
25
30
35
40
45
50
3. Requerir una implementación SCTP no estándar en tanto la eNB/HeNB origen como el concentrador. Aunque el fragmento INIT permite al emisor proporcionar múltiples Direcciones IP, eso se usa para soportar multihoming entre el emisor y el receptor y, no para proporcionar una Dirección IP adicional para identificar un par "distante". Por lo tanto, una implementación propietaria podría tener que designarse e implementarse para que tanto el emisor (eNB/HeNB) como el receptor (concentrador) utilicen la carga útil del fragmento de manera apropiada.
Alternativa de Proxy de Enrutamiento X2
Dados los inconvenientes de ambas propuestas actuales, merece la pena considerar otra solución alternativa que soportaría X2 entre eNB y HeNB independientemente de si una HeNB-GW estaba presente (o de hecho son necesarias) o no. Tal solución proporcionaría flexibilidad para satisfacer diversos requisitos de implementación. Esto introduciría la función lógica, el Proxy de Enrutamiento x2 que puede implementarse en una HeNB o no. La figura 4 ilustra la arquitectura de red aplicable con la solución propuesta y muestra una arquitectura de red lógica de acuerdo con una forma de realización.
Lo siguiente proporciona más detalles de cómo tal solución podría implementarse, resaltando ciertos escenarios clave.
Configuración X2
Uno de los escenarios clave que hay que considerar es cómo una conexión X2 podría establecerse entre eNB y HeNB. La figura 5 ilustra el procedimiento de configuración X2 "básico", es decir, cuando una eNB detecta (o se configura con información) una HeNB vecina.
En particular, La figura 5 muestra formas de realización que funcionarían cuando se implementa la función de Proxy de Enrutamiento X2.
Las etapas principales en la figura 5 son según se muestra.
1. eNB#1 detecta HeNB#2.
2. eNB#1 entonces solicita información acerca de HeNB#2 mediante los procedimientos de Transferencia de Configuración S1AP eNB/MME, que se envían mediante el MME a HeNB#2.
3. HeNB#2 proporciona dos conjuntos de configuración TNL. Información en la respuesta de Transferencia de Configuración, si primero proporciona información TNL del Proxy de Enrutamiento X2, el segundo es información TNL de la propia HeNB#2.
4. Una vez que eNB#1 ha recibido información acerca de HeNB#2, configura una Asociación SCTP al Proxy de Enrutamiento X2 usando la Información de Configuración TNL recibida.
5. Una vez que se establece una asociación SCTP, eNB#1 envía una Solicitud de Configuración X2 al nodo par. Para evitar tener que implementar comportamiento especial con respecto a la población de información de celda vecina en el mensaje X2 un nuevo IE, se introduce la identidad eNB TNL Receptores. Este nuevo IE permite que el Proxy de Enrutamiento X2 determine dónde enviar el mensaje X2.
6. Una vez que HeNB#2 recibe la Solicitud de Configuración X2, responde con una Respuesta de Configuración X2 y, como para la Solicitud de Configuración, se incluye una nueva identidad eNB TNL Receptores IE (que se configura para identificar eNB#1).
El mismo escenario se repetirá si eNB posteriormente decide establecer un X2 en otra HeNB. Similarmente, si el origen es una HeNB y el destino un eNB, el procedimiento es el mismo.
De manera similar, el mensaje de Fallo de Configuración X2 requerirá que nuevos IE identifiquen tanto la eNB/HeNB de origen y destino.
Otros procedimientos X2
Con el fin de asegurar, en caso de que un Proxy de Enrutamiento X2 se implemente, que el comportamiento del Proxy se mantenga simple y transparente, se podrían también introducir nuevos IE de "enrutamiento" (para identificar la eNB de origen/destino) en otros mensajes X2 que no soportan actualmente tal información. Mientras que esto podría requerir, por lo tanto, la adición de IE de identidad eNB-ID TNL de Origen y Destino en los mensajes X2, daría como resultado una implementación consistente y coherente en el proxy de Enrutamiento X2. Siendo un ejemplo el procedimiento de Traspaso mostrado en la figura 6.
Sumario
Como se puede ver a partir de la información anterior, la nueva solución propuesta es simple, porque solo requiere la adición de IE de "enrutamiento" en los mensajes X2 y alguna funcionalidad nueva básica en la eNB/HeNB. La funcionalidad de Proxy de Enrutamiento X2 es la capacidad para "enrutar" mensajes basándose en los IE recibidos.
Esta solución tiene ventajas sobre las propuestas existentes, que incluyen:
• Que funcionará en diversas arquitecturas de red
• No hay necesidad de implementar funcionalidad adicional en la HeNB-GW para gestionar procedimientos X2 no
5
10
15
20
25
30
35
40
45
50
55
relacionados con UE
• No hay necesidad de mantener asignaciones de celdas vecinas en la HeNB-GW
• No hay necesidad de gestionar ID X2AP en la HeNB-GW
• La solución no requiere cambios MME
• No hay necesidad de implementar SCTP no estándar
Conclusión y propuestas
Esto muestra que una solución alternativa es posible para soportar la introducción de un proxy X2 entre eNB y HeNB. Esta solución proporciona una implementación eNB/HeNB que no exige el despliegue de una HeNB-GW. Además, la complejidad de la función de proxy de enrutamiento X2 es que su nombre sugiere meramente una función de enrutamiento. También reduce los cambios que se implementarán en una eNB/HeNB en comparación con las dos soluciones existentes.
Referencias
[1] . R3-120138 - X2-proxy - NSN et al
[2] . R3-120607 - Further Clarification on X2 Proxy - NSN et al
[3] . R3-120852 - X2 SCTP Concentrator Concept - TP for H(e)NB Mobility TR - Ericsson
Por consiguiente, puede verse que, en las formas de realización, una única asociación SCTP se crea entre la macroestación base y el proxy 40. Además, una única asociación SCTP se proporciona entre el proxy u cada celda pequeña de destino soportada. Sin embargo, la asociación SCTP única entre la macroestación base y el proxy se reutiliza para cada mensaje X2AP dirigido al proxy 40, pero que el proxy 40 entonces enruta ese mensaje X2AP sobre la asociación SCTP única con la estación base de celda pequeña de destino. Por consiguiente, una finalización SCTP tiene lugar dentro del proxy, pero la asociación X2AP (y todos los procedimientos X2) se extiende desde la estación base de origen hasta la estación base de destino.
También, se puede ver que este enfoque alivia la carga sobre la macroestación base de necesitar sostener decenas, centenas o más asociaciones SCTP sobre la interfaz X2 si quiere dirigir un gran número de estaciones base tal como estaciones base de celdas pequeñas. Este enfoque permite proporcionar un proxy más simplificado en comparación con otras soluciones que finalizarían completamente el protocolo X2 dentro del proxy. Este enfoque requiere también menos cambios en el comportamiento de las estaciones base. Además, este enfoque resuelve las deficiencias técnicas que una solución de nivel de transporte puro tal como un concentrador SCTP no puede resolver, tal como el problema de gestión dinámica de flujos SCTp en las relaciones de estación base vecina que necesitan añadirse o eliminarse, o asignar flujos SCTP en el identificador de estación base.
Una persona experta en la materia podría reconocer fácilmente que las etapas de diversos procedimientos descritos anteriormente pueden realizarse por ordenadores programados. En el presente documento, algunas formas de realización se destinan también a cubrir los dispositivos de almacenamiento de programas, por ejemplo, medios de almacenamiento de datos digitales, que son legibles por máquina u ordenador y programas ejecutables por máquinas de codificación o programas ejecutables por ordenador de instrucciones, en el que dichas instrucciones realizan alguna o todas las etapas de dichos procedimientos anteriormente descritos. Los dispositivos de almacenamiento de programas pueden ser, por ejemplo, memorias digitales, medios de almacenamiento magnético tales como discos magnéticos y cintas magnéticas, discos duros o medios de almacenamiento de datos digitales legibles ópticamente. Las formas de realización también pretenden cubrir ordenadores programados para realizar dichas etapas de los procedimientos descritos anteriormente.
Las funciones de los diversos elementos mostrados en las figuras, incluyendo cualquier bloque funcional etiquetado como "procesadores" o "lógica", pueden proporcionarse a través de hardware dedicado, así como hardware capaz de ejecutar software en asociación con software apropiado. Cuando se proporciona por un procesador, las funciones pueden proporcionarse por un único procesador dedicado, por un procesador compartido o por una pluralidad de procesadores individuales, algunos de los cuales pueden compartirse. Además, el uso explícito del término "procesador" o "controlador" o "lógica" no debería construirse para referirse exclusivamente a hardware capaz de ejecutar software y, puede incluir implícitamente, sin límites, hardware de procesador de señal digital (DSP), procesador de red, circuito integrado específico de la aplicación (ASIC), matriz de puerta programable de campo (FPGA), memoria de solo lectura (ROM) para almacenar software, memoria de acceso aleatorio (RAM), y almacenamiento no volátil. Otro hardware, convencional y/o personalizado, puede incluirse también. De manera similar, cualquier interruptor mostrado en las figuras es solo conceptual. Su función puede llevarse a cabo a través de la operación de lógica programada, a través de lógica dedicada, a través de la interacción de control de programa y lógica dedicada o, incluso, manualmente, siendo la técnica particular seleccionable por el implementador, como se entiende más específicamente a partir del contexto.
Debería apreciarse por los expertos en la materia que cualquier diagrama de bloques en el presente documento representa vistas conceptuales de circuitería ilustrativa que incorporan los principios de la invención. De manera similar, se apreciará que cualquier gráfico de flujo, diagrama de flujo, diagrama de transición de estado, pseudocódigo y similares representan diversos procesos que pueden representarse sustancialmente en un medio legible por ordenador y, por lo tanto, ejecutarse por un ordenador o procesador, tanto si se muestra explícitamente
tal ordenador o procesador o no. La descripción y los dibujos ilustran meramente los principios de la invención. Por lo tanto, se apreciará que aquellos expertos en la materia podrán idear diversas disposiciones que, aunque no se describen o se muestran en el presente documento de manera explícita, incorporan los principios de la invención y se incluyen dentro de su ámbito. Además, todos los ejemplos mencionados en el presente documento pretenden 5 principalmente ser expresamente solo para fines pedagógicos para ayudar al lector a entender los principios de la invención y los conceptos aportados por el(los) inventor(es) a la promoción de la técnica y deben construirse como sin tener ninguna limitación a tales ejemplos citados y condiciones específicamente. Además, todas las afirmaciones en el presente documento que recitan principios, aspectos y formas de realización de la invención, así como ejemplos específicos de la misma, se dirigen a abarcar equivalentes de la misma.
10

Claims (8)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    REIVINDICACIONES
    1. Un procedimiento realizado por un nodo (40) proxy para transferir mensajes entre las estaciones (20, 30) base de una red de telecomunicaciones inalámbrica, comprendiendo dicho procedimiento las etapas de:
    recibir un mensaje de Protocolo de Aplicación X2 dentro de un paquete IP de interfaz X2 entrante sobre una interfaz X2 desde una estación base origen;
    extraer, desde dicho mensaje de Protocolo de Aplicación X2, información de identidad de estación base de destino que identifica una estación base de destino;
    enrutar dicho mensaje de Protocolo de Aplicación X2 a dicha estación base, portándose dicho mensaje de Protocolo de Aplicación X2 dentro de un paquete IP de interfaz X2 saliente que tiene una dirección IP de destino derivada de dicha información de identidad de estación base de destino; y
    mantener una asociación de Protocolo de Aplicación X2 directa entre dicha estación base de origen y dicha estación base de destino, portándose dicha asociación de Protocolo de Aplicación X2 sobre dos asociaciones SCTP, una desde dicha estación base de origen hasta dicho nodo proxy y una desde dicho nodo proxy hasta dicha estación base de destino.
  2. 2. El procedimiento de la reivindicación 1, en el que dicha etapa de extracción comprende extraer dicha dirección IP de destino desde dicha información de identidad de estación base de destino y dicha etapa de enrutamiento comprende enrutar dicho mensaje de Protocolo de Aplicación X2 portado dentro de dicho paquete IP de interfaz X2 saliente que tiene dicha dirección IP de destino a dicha estación base de destino.
  3. 3. El procedimiento de la reivindicación 1 o 2, que comprende la etapa de mantener una tabla de búsqueda que combine una información de identidad de estación base de destino con unas direcciones IP de estación base de destino correspondientes, dicha etapa de enrutamiento comprende identificar dicha dirección IP de destino desde dicha tabla de búsqueda que usa dicha información de identidad de estación base de destino y enrutar dicho mensaje de Protocolo de Aplicación X2 saliente portado dentro de dicho paquete IP de interfaz X2 saliente que tiene dicha dirección IP de destino a dicha estación base de destino.
  4. 4. El procedimiento de una reivindicación anterior cualquiera, en el que la etapa de recepción comprende recibir el mensaje de Protocolo de Aplicación X2 entrante en un nodo proxy que tiene una dirección IP incluida dentro del paquete IP de interfaz X2 que porta el mensaje de Protocolo de Aplicación X2 entrante.
  5. 5. El procedimiento de una reivindicación anterior cualquiera, que comprende la etapa de consultar una tabla de búsqueda externa para obtener una dirección IP de estación base de destino en respuesta para proporcionar la información de identidad de estación base de destino.
  6. 6. El procedimiento de la reivindicación 5, que comprende la etapa de recibir la dirección IP de estación base de destino para inclusión en la tabla de búsqueda durante la transferencia de mensajes de interfaz S1 con la estación base de destino.
  7. 7. Un nodo (40) proxy operable para transferir mensajes entre las estaciones base (eNB; HeNB) de una red de telecomunicaciones inalámbrica, comprendiendo dicho proxy:
    lógica de recepción operable para recibir un mensaje de Protocolo de Aplicación X2 dentro de un paquete IP de interfaz X2 entrante sobre una interfaz X2 desde una estación base de origen;
    lógica de extracción operable para extraer, desde dicho mensaje de Protocolo de Aplicación X2, información de identidad de estación base de destino que identifica una estación base de destino;
    lógica de enrutamiento operable para enrutar dicho mensaje de Protocolo de Aplicación X2 a dicha estación base de destino, portándose dicho mensaje de Protocolo de Aplicación X2 dentro de un paquete IP de interfaz X2 saliente que tiene una dirección IP de destino derivada de dicha información de identidad de estación base de destino; y lógica de interfaz operable para mantener una asociación de Protocolo de Aplicación X2 directa entre la estación base de origen y la estación base de destino, portándose la asociación de Protocolo de Aplicación X2 sobre dos asociaciones SCTP, una desde la estación base de origen hasta el nodo proxy y una desde el nodo proxy hasta la estación base de destino.
  8. 8. Un producto de programa informático operable, cuando se ejecuta en un ordenador, para realizar las etapas del procedimiento de una cualquiera de las reivindicaciones 1 a 6.
ES12360033.0T 2012-05-10 2012-05-10 Transferencia de mensajes Active ES2647445T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP12360033.0A EP2663158B1 (en) 2012-05-10 2012-05-10 Transferring messages

Publications (1)

Publication Number Publication Date
ES2647445T3 true ES2647445T3 (es) 2017-12-21

Family

ID=48083175

Family Applications (1)

Application Number Title Priority Date Filing Date
ES12360033.0T Active ES2647445T3 (es) 2012-05-10 2012-05-10 Transferencia de mensajes

Country Status (7)

Country Link
US (1) US20150109999A1 (es)
EP (1) EP2663158B1 (es)
JP (1) JP2015516132A (es)
KR (1) KR20150003273A (es)
CN (1) CN104272861A (es)
ES (1) ES2647445T3 (es)
WO (1) WO2013167335A1 (es)

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103716847B (zh) * 2012-09-28 2019-06-14 北京三星通信技术研究有限公司 一种通过网关建立x2的方法
US9451530B2 (en) 2012-11-02 2016-09-20 Telefonaktiebolaget L M Ericsson (Publ) Methods for base-station-to-base-station connection management
WO2014126441A1 (en) * 2013-02-18 2014-08-21 Lg Electronics Inc. Method and apparatus for performing x2 setup procedure in wireless communication system
CN103561481A (zh) * 2013-11-14 2014-02-05 华为技术有限公司 X2接口的自建立方法及装置
CN104661265A (zh) * 2013-11-22 2015-05-27 北京三星通信技术研究有限公司 建立x2并进行信息传输的方法及设备
WO2015134985A1 (en) * 2014-03-07 2015-09-11 Parallel Wireless, Inc Federated x2 gateway
US9954568B1 (en) * 2014-06-25 2018-04-24 Sprint Communications Company L.P. Antenna module communication control in an antenna enclosure system
US10154440B2 (en) 2014-11-14 2018-12-11 Parallel Wireless, Inc. Seamless mobile handover
FR3038475A1 (fr) * 2015-07-01 2017-01-06 Orange Procede d' optimisation de la charge d' un concentrateur de connexions reseau
US10863007B2 (en) * 2015-10-20 2020-12-08 Parallel Wireless, Inc. Xx/Xn protocol programmability
EP3366062B1 (en) * 2015-10-20 2021-09-08 Parallel Wireless, Inc. X2 protocol programmability
ES2745623T3 (es) * 2016-04-12 2020-03-03 Ericsson Telefon Ab L M Múltiples asociaciones de SCTP por conexión de S1AP y movimiento de conexión de señalización de S1AP entre asociaciones de SCTP
CN107528679B (zh) * 2016-06-22 2020-04-14 大唐移动通信设备有限公司 一种s1ap信令传输方法及装置
US10728844B2 (en) 2016-09-29 2020-07-28 British Telecommunications Public Limited Company Cellular telecommunications network
CN109804672B (zh) 2016-09-29 2022-05-10 英国电讯有限公司 蜂窝电信网络
KR102531563B1 (ko) * 2017-01-06 2023-05-12 패러렐 와이어리스, 인크. 집성 최적화를 통한 x2 중재
CN111294879B (zh) * 2017-03-29 2022-04-01 安科讯(福建)科技有限公司 一种小区切换之前配置邻区的方法及系统
EP3585025B1 (en) * 2017-03-31 2021-08-18 Huawei Technologies Co., Ltd. Data migration method and apparatus
WO2018186783A1 (en) * 2017-04-05 2018-10-11 Telefonaktiebolaget Lm Ericsson (Publ) Methods providing primary identifications of base stations and related wireless terminals and base stations
CN113660686B (zh) 2017-05-05 2023-07-21 中兴通讯股份有限公司 一种通信方法、设备和系统
US11558854B2 (en) 2017-07-18 2023-01-17 British Telecommunications Public Limited Company Cellular telecommunications network
WO2019209922A1 (en) 2018-04-24 2019-10-31 Parallel Wireless, Inc. Xx brokering with aggregation optimization
CN110830600B (zh) * 2018-08-10 2022-08-19 中兴通讯股份有限公司 地址的获取方法、地址的发送方法及装置
EP3772227B1 (en) 2019-07-29 2022-07-13 British Telecommunications public limited company Cellular telecommunications network
WO2021018449A1 (en) 2019-07-29 2021-02-04 British Telecommunications Public Limited Company Initiation of transfer of user equipment to base station according to visual data
GB2596118B (en) 2020-06-18 2022-07-20 British Telecomm Cellular telecommunications network
CN112866229B (zh) * 2021-01-13 2022-09-06 中国人民解放军国防科技大学 一种基于状态图的高速网络流量识别方法及系统
WO2023030945A2 (en) * 2021-09-06 2023-03-09 Nokia Solutions And Networks Oy Data synchronization between active and standby nodes for service continuity

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6826198B2 (en) * 2000-12-18 2004-11-30 Telefonaktiebolaget Lm Ericsson (Publ) Signaling transport protocol extensions for load balancing and server pool support
JP4229907B2 (ja) * 2002-06-07 2009-02-25 ノキア コーポレイション コネクションオリエンテッド又はコネクションレスデータを送信する方法及びシステム
CN101321101A (zh) * 2007-06-05 2008-12-10 华为技术有限公司 接入网节点自配置的方法及其系统
JP5039592B2 (ja) * 2008-02-06 2012-10-03 株式会社エヌ・ティ・ティ・ドコモ 移動通信方法及び移動通信システム
CN101541093B (zh) * 2008-03-21 2013-04-24 华为技术有限公司 一种接口连接建立及维护的方法和装置
ES2586741T3 (es) * 2008-04-30 2016-10-18 Telefonaktiebolaget L M Ericsson (Publ) Red de auto-retorno en LTE
EP2356845B1 (en) * 2008-12-10 2016-04-13 Telefonaktiebolaget LM Ericsson (publ) Interface setup for communications network with femtocells
JP5225191B2 (ja) * 2009-04-28 2013-07-03 株式会社エヌ・ティ・ティ・ドコモ 移動通信システム
CN102461316B (zh) * 2009-06-18 2015-09-30 瑞典爱立信有限公司 移动电信系统中的方法和布置
CN102457915B (zh) * 2010-10-26 2016-03-02 株式会社Ntt都科摩 管理x2接口的方法、切换方法、干扰抑制方法及装置
CN103404227B (zh) * 2011-04-28 2017-02-15 Lg电子株式会社 在无线通信系统中启动x2接口设置的方法和设备
CN103002527B (zh) * 2011-09-13 2015-04-08 华为技术有限公司 一种中继节点切换方法、基站、和通讯系统
WO2013137815A2 (en) * 2012-03-16 2013-09-19 Telefonaktiebolaget L M Ericsson (Publ) Autonomous transport layer connection setup by a transport layer concentrator
WO2013141086A1 (ja) * 2012-03-19 2013-09-26 京セラ株式会社 通信制御方法、基地局、ホーム基地局、及びゲートウェイ装置
US9276806B2 (en) * 2012-10-15 2016-03-01 Interdigital Patent Holdings, Inc. Failover recovery methods with an edge component

Also Published As

Publication number Publication date
WO2013167335A1 (en) 2013-11-14
US20150109999A1 (en) 2015-04-23
KR20150003273A (ko) 2015-01-08
EP2663158B1 (en) 2017-08-16
EP2663158A1 (en) 2013-11-13
JP2015516132A (ja) 2015-06-04
CN104272861A (zh) 2015-01-07

Similar Documents

Publication Publication Date Title
ES2647445T3 (es) Transferencia de mensajes
ES2863467T3 (es) Procedimiento y aparato para gestionar sesión para cambiar una función de plano de usuario en un sistema de comunicación inalámbrica
JP6512331B2 (ja) Ｘ２ゲートウェイを有する通信システム
TWI712324B (zh) 與傳統無線電存取技術互動工作用於連接到下一代核心網路
ES2858474T3 (es) Métodos y aparatos para proporcionar un identificador de usuario de MME
ES2881866T3 (es) Señalización en redes de comunicación móvil de doble conectividad
ES2915682T3 (es) Nodo de red de acceso por radiocomunicaciones, terminal de radiocomunicaciones y métodos y medios legibles por ordenador no transitorios para los mismos
ES2428820T3 (es) Puerta de enlace configurada para proporcionar una función de traspaso, conversión y enrutamiento
ES2946703T3 (es) Procedimiento y aparato para establecer la doble conectividad para transmitir datos en una nueva arquitectura de comunicación por radio
EP3063972B1 (en) Method to enable multiple wireless connections
ES2434695T3 (es) Gestión de QoS en LTE para una estación base de auto retroceso
EP3273748B1 (en) Base station apparatus, and inter-base-station gateway apparatus
ES2720192T3 (es) Procedimiento y aparato de transferencia en un sistema de comunicación inalámbrica
US11026136B2 (en) Handovers with simplified network topology
ES2965452T3 (es) Método y dispositivos para establecer una conexión de señalización entre un equipo de usuario, UE, remoto y una red de telecomunicaciones a través de un UE con capacidad de retransmisión
WO2020164175A1 (zh) 标识管理的方法和装置
ES2712939T3 (es) Método para proporcionar la identidad de un aparato en una red de comunicaciones y aparato del mismo
TW201004219A (en) Signaling and management of broadcast-multicast waveform embedded in a unicast waveform
WO2014177075A1 (zh) 连接建立方法与装置、系统、存储介质
Network 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network
WO2012142824A1 (zh) 小区切换方法及系统
WO2015043292A1 (zh) 一种x2消息通知的方法及家庭基站、x2网关
EP4211912A1 (en) Source and target network nodes and methods therein for preventing agents from illegitimately identifying the source network node when resuming a wireless terminal in a target network node in a wireless communications network