ES2373710T3 - Procedimiento de reubicación de srns y controlador de red radio correspondiente. - Google Patents

Abstract

Un procedimiento para realizar una reubicación de Subsistema de Red Radio de Servicio, SRNS, que comprende: - recibir en una información de recursos de radio de Controlador de Red Radio, RNC, objetivo a partir de un RNC fuente, incluyendo dicha información de recursos de radio unos parámetros de cifrado, uno de los cuales es un Número de Hipertrama, HFN; - cifrar una unidad de datos en el RNC objetivo con los parámetros de cifrado recibidos; y - transmitir la unidad de datos cifrada desde el RNC objetivo hasta un terminal de usuario, UE, caracterizado porque uno de dichos parámetros de cifrado es una variable de estado, VT(US), que indica un valor de número de secuencia que sigue de forma consecutiva el número de secuencia de una unidad de datos que se transmitió por última vez desde el RNC fuente hasta el terminal de usuario.

Description

Procedimiento de reubicación de SRNS y controlador de red radio correspondiente

Antecedentes de la invención

1. Campo de la invención

La presente invención se refiere en general a un controlador de red radio y a un procedimiento para realizar un procedimiento de reubicación de subsistema de red radio de servicio (SRNS).

2. Antecedentes de la de la técnica relacionada

Un sistema de telecomunicaciones móviles universal (UMTS) es un sistema de comunicación móvil de tercera generación que ha evolucionado a partir de una norma que se conoce como Sistema Global para comunicaciones Móviles (GSM). Esta norma es una norma europea que tiene como objetivo proporcionar un servicio de comunicación móvil mejorado en base a una red medular de GSM y a una tecnología de acceso múltiple por división de código de banda ancha (W–CDMA). En diciembre de 1998, el ETSI de Europa, el ARIB/TTC de Japón, el T1 de los Estados Unidos, y la TTA de Corea formaron un Proyecto de Asociación de Tercera Generación (3GPP) con el fin de crear una especificación para la normalización del UMTS.

El trabajo hacia la normalización del UMTS realizado por el 3GPP ha dado como resultado la formación de cinco grupos de especificación técnica (TSG), cada uno de los cuales está dirigido a la formación de unos elementos de red que tienen funciones independientes. Más específicamente, cada TSG desarrolla, aprueba, y gestiona una especificación de normas en un área relacionada. Entre éstos, un grupo de red de acceso de radio (RAN) (TSG– RAN) desarrolla una especificación para la función, los elementos deseados y la interfaz de una red de acceso de radio terrestre de UMTS (UTRAN), que es una nueva RAN para suportar una tecnología de acceso W–CDMA en el UMTS.

El grupo de TSG–RAN incluye un grupo plenario y cuatro grupos de trabajo. El grupo de trabajo 1 (WG1) desarrolla una especificación para una capa física (una primera capa). El grupo de trabajo 2 (WG2) especifica las funciones de una capa de enlace de datos (una segunda capa) y una capa de red (una tercera capa). El grupo de trabajo 3 (WG3) define una especificación para una interfaz entre una estación base en la UTRAN, un controlador de red radio (RNC), y una red medular. Finalmente, el grupo de trabajo 4 (WG4) discute términos deseados para un rendimiento de enlace de radio y elementos deseados para la gestión de recursos de radio.

La figura 1 muestra una estructura de una UTRAN de 3GPP a la que puede aplicarse la presente invención. Esta UTRAN incluye uno o más subsistemas de red radio (RNS). Cada RNS incluye un RNC y uno o más Nodos B (por ejemplo, una estación base) gestionados por los RNC. Los RNC se conectan a un centro de conmutación móvil (MSC) que realiza las comunicaciones de intercambio de línea con la red GSM. Los RNC se conectan también a un nodo de soporte de servicio de radio de paquetes general de servicio (SGSN) que realiza unas comunicaciones de intercambio de paquetes con una red de servicio de radio de paquetes general (GPRS).

Los nodos B se gestionan por los RNC, reciben una información enviada por la capa física de un terminal (por ejemplo, una estación móvil, un equipo de usuario y/o una unidad de abonado) a través de un enlace ascendente, y transmiten unos datos a un terminal a través de un enlace descendente. Los nodos B, por lo tanto, funcionan como puntos de acceso de la UTRAN para el terminal.

Los RNC realizan funciones que incluyen la asignación y gestión de recursos de radio. Se hace referencia a un RNC que gestiona directamente un Nodo B como un RNC de control (CRNC). El CRNC gestiona recursos de radio comunes. UN RNC de servicio (SRNC), por otro lado, gestiona recursos de radio dedicados que se asignan a los terminales respectivos. El CRNC puede ser el mismo que el SRNC. No obstante, cuando el terminal se desvía con respecto a la zona del SRNC y se desplaza a la zona de otro RNC, el CRNC puede ser diferente del SRNC. Debido a que las posiciones físicas de varios elementos en la red de UMTS pueden variar, es necesaria una interfaz para conectar los elementos. Los nodos B y los RNC se conectan entre sí mediante una interfaz lub. Dos RNC se conectan entre sí mediante una interfaz lur. Se hace referencia a una interfaz entre el RNC y una red medular como lu.

Los servicios que se proporcionan al UE pueden clasificarse en general en servicios de conmutación de circuitos y en servicios de conmutación de paquetes. Un servicio de teléfono de voz puede incluirse en el servicio de conmutación de circuitos y un servicio de navegación web puede incluirse en un servicio de conmutación de paquetes a través de una conexión a Internet. El servicio de conmutación de circuitos se conecta a un MSC de la red medular, y este MSC se conecta a un centro de conmutación móvil de pasarela (GMSC) para la comunicación con una o más redes externas. El GMSC gestiona las conexiones entre el MSC y las redes externas.

El servicio de conmutación de paquetes se conecta a un nodo de soporte de servicio de radio de paquetes general de servicio (GPRS) (SGSN), este nodo se conecta a un nodo de soporte de GPRS de pasarela (GGSN) de la red medular. El SGSN comunica paquetes entre el SRNC y GGSN, y el GGSN gestiona conexiones entre el SGSN y

otra red de conmutación de paquetes tal como Internet.

Una variedad de interfaces se proporcionan para realizar intercambios de datos mutuos entre estos componentes de red. Una interfaz entre un RNC y la red medular se conoce como una interfaz lu. Cuando la lu se conecta al dominio de conmutación de paquetes, ésta se denomina una interfaz de PS de lu, y cuando la lu se conecta al dominio de conmutación de circuitos ésta se denomina una interfaz de CS de lu.

La figura 2 muestra una estructura de un protocolo de interfaz de acceso de radio entre un terminal que funciona en base a una especificación de RAN de 3GPP y una UTRAN. El protocolo de interfaz de acceso de radio está formado en horizontal por una capa física (PHY), una capa de enlace de datos, y una capa de red y se divide en vertical en un plano de control para la transmisión de información de control y un plano de usuario para la transmisión de información de datos. El plano de usuario es una zona a la que se transmite la información de tráfico de un usuario tal como un paquete de IP o voz. El plano de control es una zona a la que se transmite una información de control tal como una interfaz de una red o mantenimiento y gestión de una llamada.

En la figura 2, las capas de protocolo pueden dividirse en una primera capa (L1), una segunda capa (L2), y una tercera capa (L3) en base a tres capas inferiores de un modelo de norma de interconexión de sistema abierto (OSI) que se conoce bien en un sistema de comunicación. La primera capa (L1) funciona como una capa física (PHY) para una interfaz de radio y se conecta a una capa de control de acceso a medios superior (MAC) a través de uno o más canales de transporte. La capa física transmite datos que se entregan a la capa física (PHY) a través de un canal de transporte a un receptor que usa varios procedimientos de codificación y de modulación adecuados para circunstancias radioeléctricas. El canal de transporte entre la capa física (PHY) y la capa de MAC se divide en un canal de transporte dedicado y un canal de transporte común en base a si ésta se usa exclusivamente por un único terminal o se comparte por varios terminales.

La segunda capa L2 funciona como una capa de enlace de datos y deja que varios terminales compartan los recursos de radio de una red de W–CDMA. La segunda capa L2 se divide en la capa de MAC, una capa de control de enlace de radio (RLC), una capa de protocolo de convergencia de datos de paquetes (PDCP), y una capa de control de radiodifusión/multidifusión (BMC).

La capa de MAC entrega unos datos a través de una relación de asignación apropiada entre un canal lógico y un canal de transporte. Los canales lógicos conectan una capa superior a la capa de MAC. Varios canales lógicos se proporcionan en base al tipo de información transmitida. En general, cuando se transmite la información del plano de control, se usa un canal de control. Cuando se transmite la información del plano de usuario, se usa un canal de tráfico. La capa de MAC se divide en dos capas secundarias de acuerdo con las funciones realizadas. Las dos capas secundarias son una capa secundaria de MAC–d que se encuentra en el SRNC y que gestiona el canal de transporte dedicado y una capa secundaria de MAC–c/sh que se encuentra en el CRNC y que gestiona el canal de transporte común.

La capa de RLC forma una unidad de datos de protocolo (PDU) de RLC apropiada, adecuada para la transmisión mediante las funciones de segmentación y de concatenación de una unidad de datos de servicio (SDU) de RLC que se recibe a partir de una capa superior. La capa de RLC también realiza una función de petición de repetición automática (ARQ) mediante la cual se retransmite una PDU de RLC que se perdió durante la transmisión. La capa de RLC funciona en tres modos: un modo transparente (TM), un modo sin acuse de recibo (UM), y un modo con acuse de recibo (AM). El modo que se selecciona depende del procedimiento que se usa para procesar la SDU de RLC que se recibe a partir de la capa superior. Una memoria intermedia de RLC almacena las SDU de RLC o las PDU de RLC que se reciben a partir de la capa superior. A continuación se da una explicación más detallada de los modos de funcionamiento de la capa de RLC.

La capa de protocolo de convergencia de datos de paquetes (PDCP) es una capa superior de la capa de RLC que permite que se transmitan unos elementos de datos a través de un protocolo de red tal como IP.v4 o IP.v6. Una técnica de compresión de cabecera para la compresión y la transmisión de la información de cabecera en un paquete puede usarse para una transmisión efectiva del paquete de IP.

La capa de control de radiodifusión/multidifusión (BMC) permite que un mensaje se transmita a partir de un centro de radiodifusión de células (CBC) a través de la interfaz de radio. La función principal de la capa de BMC es la planificación y la transmisión de un mensaje de radiodifusión de célula a un terminal. En general, los datos se transmiten a través de la capa de RLC que funciona en el modo sin acuse de recibo.

La capa de PDCP y la capa de BMC se conectan al SGSN debido a que se usa un procedimiento de intercambio de paquetes, y se encuentran sólo en el plano de usuario debido a que transmiten sólo datos de usuario. A diferencia de la capa de PDCP y la capa de BMC, la capa de RLC puede incluirse en el plano de usuario y el plano de control de acuerdo con una capa que se conecta a la capa superior. Cuando la capa de RLC pertenece al plano de control, los datos se reciben a partir de una capa de control de recursos de radio (RRC).

En general, se hace referencia al servicio de transmisión de los datos de usuario que se proporcionan a la capa superior mediante la segunda capa (L2) en el plano de usuario como una portadora de radio (RB). Se hace referencia al servicio de transmisión de información de control que se proporciona a la capa superior mediante la

segunda capa (L2) en el plano de control como una portadora de radio de señalización (SRB). Tal como se muestra en la figura 2, una pluralidad de entidades puede existir en las capas de RLC y de PDCP. Esto se debe a que un terminal tiene una pluralidad de RB, y una o dos entidades de RLC y sólo una entidad de PDCP se usan en general para una RB. Las entidades de la capa de RLC y de la capa de PDCP pueden realizar una función independiente en cada capa.

La capa de RRC que se encuentra en la parte más inferior de la tercera capa (L3) se define sólo en el plano de control y controla los canales lógicos, los canales de transporte, y los canales físicos en relación con el establecimiento, el restablecimiento, y la cancelación de las RB. En este momento, la configuración de la RB implica unos procesos de determinación de las características de una capa de protocolo y de un canal, que se requieren para proporcionar un servicio específico, y el establecimiento de los procedimientos de funcionamiento y parámetros detallados respectivos. Es posible transmitir mensajes de control que se reciben a partir de la capa superior a través de un mensaje de RRC.

El funcionamiento de la portadora de radio y de la capa de RLC se describirá en detalle a continuación. Tal como se analizó anteriormente, una portadora de radio (RB) es un servicio de transmisión que entrega unos datos de usuario en el plano de usuario a una capa superior a través de la segunda capa L2. El servicio de transmisión que entrega la información de control en el plano de control a la capa superior a través de la segunda capa L2 se define como una portadora de radio de señalización (SRB).

Tal como se indicó anteriormente, la capa de RLC funciona en uno de tres modos: modo transparente (TM), modo sin acuse de recibo (UM), y modo con acuse de recibo (AM).

Cuando se funciona en el modo TM, no se añade una información de cabecera a la SDU de RLC que se recibe a partir de la capa superior, no se acopla un número de secuencia a la PDU de RLC y no se realiza una retransmisión de datos. Asimismo, a pesar de que en general no se realizan la segmentación y la reagrupación de la SDU de RLC, se determina el uso de la segmentación y reagrupación cuando la portadora de radio se configura en ciertas circunstancias.

Cuando se funciona en el modo UM, no se realiza una retransmisión de las PDU de RLC ni siquiera cuando tiene lugar un fallo de transmisión. El receptor no solicita la retransmisión de datos. En su lugar, se toma un enfoque diferente. En el modo UM, la capa de RLC construye las PDU de RLC segmentando o concatenando las SDU de RLC, y acoplando a continuación unos números de secuencia a las PDU de RLC. El receptor puede restaurar datos perdidos en base a los números de secuencia mediante un procedimiento de reagrupación.

Cuando se funciona en el modo AM, se usa una retransmisión para soportar una transmisión sin error de la siguiente forma. La información de estatus que se corresponde con las PDU de RLC recibidas se transmite a partir del receptor en la forma de un Informe de Estatus. Después de recibir este informe, el transmisor retransmite las PDU de RLC transmitidas sin éxito.

Más específicamente, en el modo AM, el transmisor forma cada PDU de RLC a partir de una o más SDU de RLC que se han recibido a partir de una capa superior, y una información de cabecera, (por ejemplo un número de secuencia y unos indicadores de longitud) se acoplan a continuación. Debido a que el tamaño de una PDU de RLC de AM es fijo, el transmisor segmenta o concatena una o más SDU de RLC para corresponderse con el tamaño de PDU. A continuación, la PDU de RLC formada se almacena en la memoria intermedia de transmisión. Las PDU de RLC almacenadas se entregan de forma secuencial a la capa de MAC a una velocidad controlada mediante la capa de MAC. Debido a que cada PDU de RLC tiene su propio número de secuencia, el receptor puede comprobar cuáles de las PDU de RLC se reciben con éxito y cuáles no. El receptor solicita la retransmisión para las PDU de RLC recibidas sin éxito al transmisor mediante el Informe de Estatus.

El procedimiento de retransmisión de AM puede entenderse más claramente mediante el siguiente ejemplo. Si los números de secuencia de las PDU de RLC recibidas son #23, #24, #25, #32, y #34, el receptor considera que las PDU de RLC que tienen los números de secuencia de #26 a #31 y #33 se han perdido durante la transmisión. El receptor envía a continuación un Informe de Estatus al transmisor, y el transmisor comprueba el Informe de Estatus, y retransmite las PDU de RLC transmitidas sin éxito, es decir de #26 a #31 y #33.

La figura 3 muestra la estructura de una PDU de RLC de modo AM o UM que se usa en la capa de RLC. La PDU de RLC está compuesta por una cabecera y una carga útil. La cabecera que se muestra incluye un número de secuencia y un indicador de longitud. El número de secuencia se usa como un identificador de la PDU de RLC correspondiente, y el indicador de longitud indica un límite de la SDU de RLC. Los números de secuencia pueden ser, por ejemplo, 7 (siete) bits para el modo UM, y 12 (doce) bits para el modo AM. Un campo E de 1 (un) bit puede incluirse para indicar si el siguiente campo es el indicador de longitud o datos.

El indicador de longitud se usa para indicar el límite de cada SDU de RLC que finaliza dentro de la PDU de RLC. Por lo tanto, el indicador de longitud puede no estar presente si la SDU de RLC no se finaliza dentro de la PDU de RLC. El indicador de longitud puede usarse también para otros fines. Por ejemplo, el indicador de longitud puede usarse como un indicador de relleno y/o un indicador de inicio de datos. El relleno se usa para llenar la totalidad de la PDU de RLC cuando no hay una SDU de RLC a concatenar. El relleno puede tener cualquier valor y el receptor y el

emisor descartar éste. Cuando se usa como un indicador de inicio de datos, el indicador de longitud puede indicar que la SDU de RLC se inicia en el inicio de la PDU de RLC.

El indicador de inicio de datos es útil debido a que puede evitar una pérdida adicional de datos en el RLC de UM. Por ejemplo, supóngase que una PDU de RLC de número de secuencia #4 se ha perdido y que se recibe una PDU de RLC de número de secuencia #5. Supóngase además que una SDU de RLC nueva se inicia en el inicio de la PDU de número de secuencia #5 y finaliza dentro de la PDU de número de secuencia #5. En este caso, debido a que la SDU de RLC se inicia en el inicio de la PDU de número de secuencia #5, el indicador de inicio de datos se encuentra presente en la cabecera de la PDU de número de secuencia #5. En cambio, si el indicador de inicio de datos no se encuentra presente, la capa de RLC de receptor considera que sólo se reciben unos segmentos continuados de una SDU de RLC contenida en la PDU de RLC de número de secuencia #5. En este caso, el receptor descarta los segmentos debido a que el receptor piensa que no se ha recibido la totalidad de la SDU de RLC.

La figura 4 muestra una imagen a modo de ejemplo del Estatus de una memoria intermedia de RLC. Tal como se muestra, las PDU de RLC se almacenan de forma secuencial en la memoria intermedia y las PDU de RLC transmitidas con éxito se borran de la memoria intermedia. Tal como se muestra, la capa de RLC usa unas variables de estado para gestionar la transmisión de datos que usa la memoria intermedia de RLC.

Cuando se funciona en el modo AM, la capa de RLC usa una variable de estado VT(S) para indicar el número de secuencia de la siguiente PDU de RLC que va a transmitirse por primera vez, y una variable de estado VT(A) para indicar el número de secuencia de la primera PDU de RLC de la que va a dar acuse de recibo de forma positiva el receptor. El Estatus de la memoria intermedia indica por lo tanto que el transmisor tiene las PDU de RLC transmitidas hasta la PDU de número de secuencia de VT(S)–1 y ha recibido acuses de recibo positivos hasta la PDU de RLC de VT(A)–1 del receptor.

Cuando se funciona en el modo UM, la capa de RLC usa una variable de estado VT(US) que es similar a VT(S) en el modo AM. Es decir, VT(US) indica el número de secuencia de la siguiente PDU de RLC que va a transmitirse. No obstante, debido a que no hay realimentación a partir del receptor en el modo UM, no se define la variable de estado tal como VT(A).

En ambos modos de funcionamiento, el valor inicial de las variables de estado puede ajustarse a 0 (cero). Cuando la capa de RLC se establece, restablece o reajusta, las variables de estado se ajustan a este valor inicial.

Volviendo a continuación al protocolo de comunicaciones de radio que se muestra en la figura 2, tal como se indica anteriormente, el servicio que se proporciona a la capa superior mediante la segunda capa L2 en el plano de control se define como una portadora de radio de señalización (SRB). En funcionamiento, todos los mensajes de RRC se intercambian entre el terminal y el RNC a través de las portadoras de radio de señalización SRB. Usando los mensajes de RRC, el RNC puede configurar, modificar, y liberar las portadoras de radio según sea necesario con el fin de, por ejemplo, realizar un procedimiento de reubicación de SRNS, los detalles del cual se describen en mayor detalle a continuación.

Las características de portadora de radio de señalización (SRB) tal como se indica anteriormente se determinan en base al modo de funcionamiento del RLC y al tipo de canal lógico que se usa. Un canal de control común (CCCH) y un canal de control dedicado (DCCH) se usan para las SRB. El CCCH es un canal lógico que porta una información de control común hasta varios terminales. Debido a que el CCCH es un canal lógico común, el CCCH contiene una identidad temporal de red radio UTRAN (U–RNTI) para identificar un terminal específico. El DCCH es un canal lógico que porta una información de control dedicada hasta un terminal específico.

Las características de cada tipo de SRB son tal como sigue.

SRB0: Para el enlace ascendente (UL) se usa un RLC de TM, y para el enlace descendente (DL) se usa un RLC de UM. El canal lógico que se usa para la SRB0 es el CCCH.

SRB1: se usa un RLC de UM, y el canal lógico es el DCCH.

SRB2: se usa un RLC de AM, y el canal lógico es el DCCH. La SRB2 porta sólo los mensajes que se generan en la capa de RRC. La SRB2 no porta los mensajes de la capa superior.

SRB3: se usa un RLC de AM, y el canal lógico es el DCCH. La SRB3 porta los mensajes que se reciben a partir de la capa superior.

SRB4: se usa un RLC de AM, y el canal lógico es el DCCH. La SRB4 también porta los mensajes que se reciben a partir de la capa superior. La diferencia es que la SRB3 porta mensajes de una prioridad más alta mientras que la SRB4 porta mensajes de una prioridad más baja.

SRB5–31: se usa un RLC de TM, y el canal lógico es el DCCH. Estas SRB se usan opcionalmente.

Procedimiento de Reubicación de SRNS

La figura 5 es un diagrama que muestra cómo un procedimiento de subsistema de red radio de servicio (SRNS) puede realizarse en un dominio de servicio que se basa en una conmutación de paquetes. Tal como se muestra, este procedimiento implica cambiar el RNS que da servicio a un terminal de usuario desde un RNS (o RNC) a otro. Cuando se realiza este cambio, se prefiere establecer la ruta más corta entre el terminal y la red medular cambiando el punto de conexión de lu. Tal como se muestra adicionalmente, cambiar el punto de conexión de lu puede en algunos casos dar lugar a que la red medular se conmute desde un SGSN (SGSN Antiguo) a otro (SGSN nuevo) con fines de realizar comunicaciones con el terminal de usuario. El procedimiento de reubicación de SRNS puede también realizarse en el dominio de servicio que se basa en una conmutación de circuitos.

Un procedimiento de reubicación de SRNS puede realizarse por al menos los siguientes motivos:

•

Cambio de Punto de Conexión: se realiza una Reubicación para desplazar la UTRAN hasta un punto de conexión de CN en el lado de UTRAN desde el RNC fuente hasta el RNC objetivo.

•

Traspaso Definitivo Combinado: se realiza una Reubicación para desplazar la UTRAN hasta un punto de conexión de CN en el lado de UTRAN desde el RNC fuente hasta el RNC objetivo, mientras que se realiza un traspaso definitivo decidido por la UTRAN.

•

Actualización de URA/ Célula combinada: se realiza una Reubicación para desplazar la UTRAN hasta el punto de conexión de CN en el lado de UTRAN desde el RNC fuente hasta el RNC objetivo, mientras que se realiza una reselección de célula en la UTRAN.

Tal como se discutirá en mayor detalle, un procedimiento de reubicación de SRNS puede requerir el uso de diferentes portadoras de radio dependiendo del modo de funcionamiento de la capa de RLC.

La reubicación de SRNS se clasifica normalmente en dos casos: (1) caso de terminal no involucrado (Caso I) y (2) caso de terminal involucrado (Caso II). En el Caso I, la reubicación de SRNS se inicia por una decisión propia de la red y el terminal no conoce si se realiza la reubicación de SRNS hasta que el procedimiento de Reubicación ha terminado. En el Caso II, la reubicación de SRNS se inicia como resultado de la solicitud de cambio de célula del terminal (por ejemplo, un traspaso) y el terminal conoce la reubicación de SRNS en el inicio del procedimiento. A pesar de que los Casos I y II son diferentes en que uno está involucrado con el terminal y el otro no lo está, ninguno de los dos casos tiene una diferencia sustancial con respecto al procedimiento de reubicación de SRNS. Una explicación más detallada de este procedimiento sigue a continuación.

Durante el procedimiento de reubicación de SRNS, varios mensajes de señalización se intercambian entre el terminal y un RNC, entre ese RNC y otro RNC, y entre uno de los RNC y la red medular.

La figura 6 muestra el intercambio de mensajes de señalización que tiene lugar entre el terminal y la red medular en el procedimiento de reubicación de SRNS del UMTS. En este intercambio, el “RNC fuente” es el RNC que juega el papel del SRNC antes de la reubicación de SRNS y el “RNC objetivo” es el RNC que juega el papel del SRNC después de la reubicación de SRNS. De forma similar, el “SGSN antiguo” es el SGSN antes del procedimiento de Reubicación y el “SGSN nuevo” es el SGSN después del procedimiento de Reubicación. A pesar de que los SGSN antiguo y nuevo tal como si fueran diferentes, los SGSN antiguo y nuevo pueden ser el mismo en ciertas circunstancias. Además, el procedimiento que se muestra en la figura 6 puede aplicarse tanto al Caso I como al Caso II.

Las etapas del procedimiento de reubicación de SRNS se resumirán a continuación. En una etapa inicial, la etapa 1, el RNC fuente decide realizar una reubicación de SRNS. O bien el Caso I o bien el Caso II puede usarse para activar el procedimiento de Reubicación.

En la etapa 2, el RNC fuente envía un mensaje de Reubicación Requerida al SGSN antiguo. El mensaje de Reubicación Requerida incluye una información para realizar, por ejemplo, la coordinación de la reubicación, la funcionalidad de seguridad, la información de contexto de protocolo de RRC, y las capacidades del terminal.

En la etapa 3, el SGSN antiguo determina a partir del mensaje de reubicación requerida si la reubicación de SRNS es una reubicación de SRNS intra–SGSN o inter–SGSN. Un procedimiento intra–SGSN se realiza cuando los SGSN antiguo y el nuevo son el mismo, y un procedimiento inter–SGSN se realiza cuando los dos son diferentes. Un mensaje de Solicitud de Reubicación Hacia Delante puede aplicarse sólo en el caso de una reubicación de SRNS inter–SGSN.

En la etapa 4, el SGSN nuevo envía un mensaje de Solicitud de Reubicación al RNC objetivo de tal modo que los recursos necesarios se asignan entre el RNC objetivo y el SGSN nuevo. Después de que se asignan con éxito todos los recursos necesarios, el RNC objetivo envía el mensaje de Acuse de Recibo de Solicitud de reubicación al SGSN nuevo.

En la etapa 5, cuando se ha asignado un recurso para la transmisión de los datos de usuario entre el RNC objetivo y

el SGSN nuevo y el SGSN nuevo está listo para la reubicación de SRNS, el mensaje de Respuesta de Reubicación Hacia Delante se envía desde el SGSN nuevo hasta SGSN antiguo.

En la etapa 6, el SGSN antiguo continúa la reubicación de SRNS enviando un mensaje de Instrucción de Reubicación al RNC fuente. El RNC fuente está listo para reenviar los datos de usuario de enlace descendente directamente al RNC objetivo.

En la etapa 7, cuando el RNC fuente está listo para el reenvío de datos, activa la ejecución de la reubicación de SRNS enviando un mensaje de Compromiso de Reubicación al RNC objetivo.

En la etapa 8, el RNC fuente se inicia para reenviar datos para el acceso de portadoras de radio. El reenvío de datos puede llevarse a cabo a través de la interfaz lu, lo que significa que los datos no se intercambian directamente entre el RNC fuente y el RNC objetivo sino a través de la red medular.

En la etapa 9, el RNC objetivo envía un mensaje de Detección de Reubicación al SGSN nuevo. Cuando se envía el mensaje de Detección de Reubicación, el RNC objetivo inicia el funcionamiento de SRNC.

En la etapa 10, el RNC objetivo envía un mensaje de información de movilidad de UTRAN (Caso I) o un mensaje de actualización de Célula/URA (zona de registro de UTRAN) (Caso II) al terminal. Ambos mensajes contienen elementos de información de terminal y elementos de información de red medular. Los elementos de información de terminal incluyen una U–RNTI nueva que se usa para la identificación del terminal en el RNC objetivo. Los elementos de información de red medular incluyen una identificación de zona de localización y una información de identificación de zona de encaminamiento.

Tras la recepción del mensaje de Información de Movilidad de UTRAN el terminal puede comenzar a enviar datos de usuario de enlace ascendente (UL) al RNC objetivo. Cuando el terminal se ha reconfigurado a sí mismo, éste envía el mensaje de Confirmación de Información de Movilidad de UTRAN al RNC objetivo. Esto indica que el terminal está listo también para recibir datos de enlace descendente (DL) desde el RNC objetivo.

En la etapa 11, tras la recepción del mensaje de Detección de Reubicación la red medular conmuta el plano de usuario desde el RNC fuente hasta el RNC objetivo. En el caso de una reubicación de SRNS inter–SGSN, el SGSN nuevo envía mensajes de Solicitud de Contexto de PDP de Actualización a los GGSN implicados. Los GGSN actualizan sus campos de contexto de PDP y devuelven una Respuesta de Contexto de PDP de Actualización.

En la etapa 12, cuando el RNC objetivo recibe el mensaje de Confirmación de Información de Movilidad de UTRAN, (es decir, la U–RNTI nueva se intercambia con éxito con el terminal por los protocolos de radio), el RNC objetivo envía el mensaje de reubicación Completa al SGSN nuevo. El fin del mensaje de reubicación Completa es indicar mediante el RNC objetivo la compleción de la reubicación del SRNS a la red medular. En el caso de una reubicación de SRNS inter–SGSN, el SGSN nuevo envía una señal al SGSN antiguo de la compleción del procedimiento de reubicación de SRNS enviando un mensaje de Reubicación Hacia Delante Completa.

En la etapa 13, tras la recepción del mensaje de reubicación Completa o del mensaje de Reubicación Hacia Delante Completa, el SGSN antiguo envía un mensaje de Instrucción de Liberación de lu al RNC fuente de tal modo que se libera la conexión de lu entre el RNC fuente y el SGSN antiguo.

La figura 7 muestra las etapas del procedimiento de reubicación de SRNS que incluye el intercambio de mensajes de RRC entre la UTRAN y el terminal. En esta figura, los mensajes de RRC se transmiten en las etapas 1, 7, y 8, y la UTRAN puede o bien ser el RNC fuente o bien el RNC objetivo que depende del caso. Asimismo, el UE se refiere al equipo de usuario y por lo tanto puede incluir un terminal de usuario. Los mensajes de RRC que se transmiten en este procedimiento se describen tal como sigue.

(1)

mensaje de Actualización de Célula y mensaje de Confirmación de Actualización de Célula: Cuando el terminal se desplaza a una célula nueva, un mensaje de Actualización de Célula se envía desde el terminal hasta la UTRAN. Si la UTRAN decide realizar una reubicación de SRNS, el RNC objetivo envía el mensaje de Confirmación de Actualización de Célula al terminal como respuesta al mensaje de Actualización de Célula. El mensaje de Confirmación de Actualización de Célula contiene la U–RNTI nueva, que indica al terminal el procedimiento de reubicación de SRNS que se está realizando. El mensaje de Actualización de Célula se transmite a través de la SRB0 usando un RLC de TM, y el mensaje de Confirmación de Actualización de Célula se transmite a través de o bien una SRB0 o bien una SRB1 usando un RLC de UM.

(2)

mensaje de Actualización de URA y mensaje de Confirmación de Actualización de URA: una URA (zona de registro de UTRAN) es una zona compuesta por una o varias células, y se conoce internamente por la UTRAN. Las URA pueden solaparse parcialmente con el fin de evitar un efecto de rebote del terminal. Por lo tanto, una célula puede pertenecer a una o más URA. El terminal conoce la identidad de URA actual a partir de la radiodifusión de la lista de URA en cada célula y realiza el procedimiento de Actualización de URA siempre que se cambia la URA. El procedimiento de Actualización de URA se inicia cuando el terminal envía el mensaje de Actualización de URA a la UTRAN. La UTRAN transmite el mensaje de Confirmación de Actualización de URA en respuesta al mensaje de Actualización de URA al terminal, con el fin de informar al terminal de la nueva identidad de

URA. El mensaje de Confirmación de Actualización de URA incluye una U–RNTI nueva que es la misma que en el mensaje de Confirmación de Actualización de Célula. El mensaje de Actualización de URA se transmite a través de la SRB0 usando un RLC de TM, y el mensaje de Confirmación de Actualización de URA se transmite a través de la SRB0 o de la SRB1 usando un RLC de UM.

(3) mensaje de Información de Movilidad de UTRAN y mensaje de Confirmación de Información de Movilidad de UTRAN: El mensaje de Información de Movilidad de UTRAN se usa cuando la UTRAN asigna una U–RNTI nueva al terminal o cuando se transmite una información de movilidad. El terminal transmite un mensaje de Confirmación de Información de Movilidad de UTRAN en respuesta. Después de la transmisión con éxito del mensaje de Confirmación de Información de Movilidad de UTRAN, el RNC objetivo y el terminal establecen/ restablecen las entidades de RLC y PDCP usando unas instrucciones de Solicitud de CONFIG de CPDCP y de Solicitud de CONFIG de CRLC, respectivamente. El mensaje de Información de Movilidad de UTRAN se transmite a través de la SRB1 usando un RLC de UM o de la SRB2 usando un RLC de AM. El mensaje de Confirmación de Información de Movilidad de UTRAN se transmite a través de la SRB2 usando un RLC de AM.

Cifrado

El procedimiento de reubicación de SRNS se ha descrito en términos de las etapas que se toman tanto en el sistema UMTS como en la UTRAN. A partir de la presente descripción, es evidente que el procedimiento de reubicación de SRNS se basa principalmente en el intercambio de mensajes entre el terminal y el RNC, y entre el RNC y la red medular. Entre estos mensajes, los mensajes de RRC que se intercambian entre el terminal y el RNC se cifran normalmente con fines de seguridad.

En algunos casos, los mensajes de RRC cifrados no pueden descifrarse en el receptor debido a que los parámetros de cifrado son diferentes entre el terminal y la UTRAN. Con el fin de obtener una mejor comprensión de este problema, el procedimiento de cifrado en general ha de considerarse en primer lugar.

El cifrado es un procedimiento que evita un acceso de datos no autorizado, por ejemplo, como resultado de escuchas no autorizadas. Debido a que existen unos parámetros de cifrado únicos entre el terminal y el RNC, un usuario que no conoce los parámetros de cifrado no puede descifrar los datos.

El procedimiento de cifrado adoptado por el 3GPP se realiza en la capa de RLC o en la capa de MAC de acuerdo con el modo de funcionamiento de RLC. Es decir, cuando el modo de RLC es AM o UM, el cifrado se realiza en la capa de RLC. Cuando el modo de RLC es TM, el cifrado se realiza en la capa de MAC. Preferentemente, en este sistema el cifrado se aplica sólo para los canales DCCH y DTCH.

Durante este procedimiento de cifrado, una MÁSCARA que se usa para el cifrado se genera en base a variosparámetros de entrada. La MÁSCARA se añade a continuación a las PDU de RLC o a las SDU de MAC para generar los datos cifrados. En el terminal de usuario, la misma MÁSCARA se usa para descifrar los datos.

La figura 8 muestra unas etapas incluidas en el proceso de cifrado. En este caso, el BLOQUE de TEXTO SINFORMATO son los datos antes del cifrado y el BLOQUE de SECUENCIA de CLAVES es una MÁSCARA de cifrado. El BLOQUE de TEXTO SIN FORMATO se cifra a un BLOQUE de TEXTO CIFRADO a través de una operación de bits con el BLOQUE de SECUENCIA de CLAVES. A continuación, el BLOQUE de TEXTO CIFRADO cifrado se transmite a una interfaz de radio. Después de recibir el BLOQUE de TEXTO CIFRADO, el receptor lo descifraaplicando el BLOQUE de SECUENCIA de CLAVES que es la misma MÁSCARA que en el transmisor. Es decir, si los datos cifrados se extraen durante la transmisión, los datos no pueden descifrarse a menos que se conozca el BLOQUE de SECUENCIA de CLAVES.

La tecnología de cifrado central subyace en la generación del BLOQUE de SECUENCIA de CLAVES, es decir laMÁSCARA de cifrado. Para obtener unos resultados efectivos, la MÁSCARA ha de tener las siguientescaracterísticas. En primer lugar, la generación de la MÁSCARA mediante un análisis inverso ha de ser imposible. Ensegundo lugar, cada portadora de radio RB ha de tener su propia MÁSCARA. En tercer lugar, la MÁSCARA ha de cambiar continuamente a lo largo del tiempo.

Entre los varios algoritmos de cifrado que existen, un procedimiento al que se hace referencia como F8 se ha adoptado por los sistemas de comunicaciones de 3GPP. El algoritmo F8 genera el BLOQUE de SECUENCIA de CLAVES usando unos parámetros de entrada que incluyen:

CK (clave de cifrado, 128 bits): Hay una CKCS para un dominio de servicio que se basa en una conmutación de circuitos y una CKPS para un dominio de servicio que se basa en una conmutación de paquetes. PORTADORA (Identificador de Portadora de radio, 5 bits): Un valor existe para cada RB.DIRECCIÓN (Identificador de Dirección, 1 bit): Indica la dirección de la RB. Se ajusta a 0 para el enlace ascendente y a 1 para el enlace descendente. LONGITUD (16 bits): Indica la longitud del BLOQUE de SECUENCIA de CLAVES, es decir la MÁSCARA generada. CONTEO–C (32 bits): un número de secuencia cifrado. Para las RB que usan RLC de AM o de UM, se usa

un CONTEO–C para cada RB. Para las RB que usan un RLC de TM, se usa un valor de CONTEO–C para todas las RB. Los expertos en la técnica pueden apreciar que los valores de bits y otros que se proporcionan anteriormente son valores preferidos y que pueden cambiarse si se desea.

Entre los parámetros de entrada de cifrado, CONTEO–C es el único parámetro que varía con el tiempo. Es decir, se usan diferentes valores de CONTEO–C para cada PDU. Otros parámetros de entrada de cifrado son parámetros fijos y por lo tanto pueden usarse los mismos valores para estos parámetros para todas las PDU en un flujo de datos. El parámetro CONTEO–C se divide en dos partes: una parte delantera y una parte trasera. La parte delantera incluye un número de secuencia largo y la parte trasera incluye un número de secuencia corto.

La figura 9 muestra unas estructuras detalladas del parámetro CONTEO–C para los varios modos de funcionamiento de la capa de RLC. Las estructuras respectivas son tal como sigue:

Caso de RLC de TM

-

número de secuencia largo: número de hipertrama (HFN) de MAC–d de 24 bits

-

número de secuencia corto: número de trama de conexión (CFN) de 8 bits

Caso de RLC de UM

-

número de secuencia largo: número de hipertrama (HFN) de RLC de 25 bits

-

número de secuencia corto: número de secuencia (SN) de UM de RLC de 7 bits

Caso de RLC de AM

-

número de secuencia largo: número de hipertrama (HFN) de RLC de 20 bits

-

número de secuencia corto: número de secuencia (SN) de AM de RLC de 12 bits

El CFN es un contador para sincronizar los canales de transporte de la capa de MAC entre el terminal y la UTRAN. El CFN puede tener un valor entre 0 y 255 y éste se aumenta en uno para cada trama de radio (10 ms).

El SN de RLC es un número de secuencia que se usa para la identificación de cada PDU de RLC. Para un RLC de UM, el SN de RLC tiene un valor entre 0 y 127 (7 bits). Para un RLC de AM, el SN de RLC tiene un valor entre 0 y

4.095 (12 bits). El SN de RLC se aumenta en 1 para cada PDU de RLC.

Debido a que un número de secuencia corto es demasiado corto para usarse solo para CONTEO–C, un número de secuencia largo que se conoce como HFN se añade delante del número de secuencia corto. Más específicamente, el HFN se corresponde con los MSB (Bits Más Significativos) y el número de secuencia corto se corresponde con los LSB (Bits Menos Significativos) del CONTEO–C. Por lo tanto, el HFN se aumenta en 1 cuando el número de secuencia corto se desborda a 0. El ajuste de este HFN es uno de los factores que da lugar a que se produzcan problemas de cifrado en los sistemas de la técnica relacionada, detalles de lo cual se analizarán a continuación.

Inconvenientes de los Procedimientos de Reubicación de SRNS de la Técnica relacionada

Se producen problemas de cifrado normalmente cuando los HFN acaban perdiendo la sincronización entre las entidades de RLC del terminal y el RNS (o RNC) en la UTRAN. Este problema de sincronización puede atribuirse principalmente al parámetro CONTEO–C. Más específicamente, tal como se analizó anteriormente, todos los parámetros de cifrado excepto CONTEO–C son parámetros fijos y por lo tanto pueden permanecer sincronizados a lo largo de la conexión. El número de secuencia corto (es decir los LSB del CONTEO–C) está también sincronizado debido a que, para un RLC de TM, el CFN es conocido tanto por el terminal como por la UTRAN y, para un RLC de UM y de AM, el SN de RLC se incluye en la cabecera de PDU y se transmite a través de la interfaz de radio. Para un RLC de TM, el número de secuencia largo que se corresponde con el HFN está también sincronizado debido a que el CFN se calcula a partir del SFN (número de trama de sistema) que se radiodifunde continuamente en una célula. Para un RLC de UM y de AM, no obstante, el HFN está a veces sin sincronización debido a las PDU de RLC perdidas o retransmitidas. Esta condición se explica en mayor detalle a continuación.

En condiciones normales, el HFN no se intercambia nunca y se gestiona localmente por el terminal y la UTRAN. Los HFN gestionados localmente pueden acabar perdiendo la sincronización para los modos de RLC de UM y de AM cuando las PDU de RLC se han perdido o retransmitido, tal como se menciona anteriormente. Si los valores de HFN que se gestionan por el terminal y la UTRAN se hacen diferentes, a continuación las MÁSCARAS que se usan en el terminal y la UTRAN también se hacen diferentes. Como resultado, los datos cifrados no pueden descifrarse en el receptor. Por lo tanto, una vez que los HFN acaban perdiendo la sincronización, no puede realizarse con éxito una transmisión de datos hasta que se sincronizan los HFN.

Los problemas en el procedimiento de reubicación de SRNS de la técnica relacionada se producen cuando este problema de cifrado (es decir, unos HFN no sincronizados) surge en el funcionamiento de RLC de UM y de AM. En la figura 7, estos problemas afectan a las etapas 7 y 8. La forma en la que las etapas se ven afectadas de manera perjudicial se describirá en detalle a continuación. (Obsérvese que la etapa 1 no presenta un problema de cifrado

debido a que el mensaje de RRC se transmite usando un RLC de TM).

Problemas en la etapa 7.

En el Caso I (UE no involucrado) y en el Caso II (UE involucrado), los mensajes de RRC se transmiten al terminal que usa una portadora de radio de servicio SRB apropiada. La capa de RLC en el RNC objetivo se genera de nuevo y se inicializan las variables de Estatus y los temporizadores. Como resultado de esta inicialización, el número de secuencia de la PDU de RLC que se transmite desde la capa de RLC en el RNC objetivo hasta el terminal se inicializa a 0 (cero). La capa de RLC de terminal, no obstante, puede estar esperando que la siguiente PDU que recibe tenga un número de secuencia diferente. Los problemas posibles en la transmisión de mensajes de RRC que resultan de esta discrepancia se describirán para cada uno de estos casos.

(1)

El mensaje de Información de Movilidad de UTRAN se transmite a través de la SRB1: En este caso, el procedimiento de Reubicación se realiza durante un modo de funcionamiento de RLC de UM. Durante este procedimiento, el HFN de UTRAN se transfiere desde el RNC fuente hasta el RNC objetivo y el RNC objetivo transmite una unidad de datos de protocolo (PDU) que incluye el HFN de UTRAN al terminal. Tal como se explicó anteriormente, no obstante, antes de que la PDU se transmita su número de secuencia se inicializa a algún número, por ejemplo, a cero. En la mayoría de los casos, este valor inicializado no se corresponde con el número de secuencia de la siguiente PDU que el terminal espera recibir. Como resultado, cuando el terminal recibe la PDU con su número de secuencia inicializado, éste concluye que una o más PDU no se han recibido con éxito, por ejemplo, hay algunas PDU perdidas. El terminal funcionará por lo tanto en base a la suposición de que se ha producido una condición de desbordamiento de número de secuencia de RLC. Cuando se detecta esta condición, el RLC de transmisor modificará su información de cifrado aumentando su parámetro de HFN en uno. Esto presenta el siguiente problema. Cuando el procedimiento de Reubicación dio lugar a que el RNS de servicio (SRNS) cambiara desde el RNC fuente hasta el RNC objetivo, el valor del parámetro de HFN no se cambió. Como resultado, el RNC objetivo transmitirá las PDU con el valor de HFN de UTRAN original. El terminal, no obstante, intentará descifrar estas PDU con el valor de HFN recién aumentado. Debido a que el terminal y la UTRAN están funcionando en base a unos valores de HFN diferentes, se considera que el terminal y la UTRAN (el RNC objetivo) han perdido la sincronización y el transmisor no será capaz de descifrar ninguna PDU a partir de la UTRAN.

(2)

El mensaje de Información de Movilidad de UTRAN se transmite a través de la SRB2: En este caso, el procedimiento de Reubicación se realiza durante el modo de funcionamiento de RLC de AM, y el RLC de terminal sólo acepta las PDU que tengan unos números de secuencia que caigan dentro de un intervalo válido, que se mantiene con fines de una gestión eficiente de las retransmisiones de datos. Este intervalo válido se define por el tamaño y la posición de una ventana de recepción que se mantiene por el receptor de terminal durante el funcionamiento de AM. Cuando el terminal recibe las PDU de RLC que se encuentran fuera de la ventana de recepción, el terminal simplemente descarta estas PDU. Durante el procedimiento de Reubicación, la siguiente PDU que se transmite al terminal tiene un número de secuencia que se ha inicializado a cero. Si este número de secuencia se encuentra fuera de la ventana de recepción del transmisor, éste se descartará inmediatamente. No obstante, incluso si el número de secuencia se encuentra dentro del intervalo de la ventana de recepción, la PDU no será capaz de descifrarse por el transmisor. Esto se debe a que el siguiente número de secuencia que espera recibir el terminal no se corresponde con el número de secuencia de la PDU recibida. El terminal concluirá por lo tanto que existen unas PDU perdidas y que se ha producido una condición de desbordamiento con respecto a los números de secuencia de PDU. Cuando se detecta esta condición, el RLC de transmisor modificará su información de cifrado aumentando su parámetro de HFN en uno, dando lugar de ese modo a que el HFN del terminal y el HFN de la UTRAN sean diferentes. Esta discrepancia evitará que el terminal descifre ningunos datos a partir de la UTRAN

(3)

El mensaje de Confirmación de Actualización de URA/ Célula se transmite a través de la SRB1: En este caso, el procedimiento de Reubicación se realiza durante el funcionamiento de RLC de UM. Tiene lugar el mismo problema que en (1) anteriormente, es decir, los mensajes de RRC que se transmiten desde el RNC objetivo en la etapa 7 no pueden descifrarse por el terminal debido a una discrepancia en los valores de HFN que tiene lugar como resultado de la inicialización del número de secuencia de la siguiente PDU que se transmite a partir de la UTRAN.

En todos los casos anteriores, el terminal y la UTRAN no serán capaces de comunicarse después de que se ha realizado la reubicación de SRNS a menos que y hasta que se ha resuelto el problema de falta de sincronización con respecto a sus HFN. Las complicaciones que surgen en conexión con la etapa 8 se analizarán a continuación.

Problemas en la etapa 8.

En el Caso I (UE no involucrado) y en el Caso II (UE involucrado), el terminal transmite un mensaje de Confirmación de Información de Movilidad de UTRAN a través de la SRB2 cuando el procedimiento de Reubicación se realiza durante el modo de funcionamiento de RLC de AM. Los problemas similares tienen lugar tal como se indica en (2) anteriormente para la etapa 7. La diferencia es que los papeles se invierten, es decir, el transmisor es el RLC de terminal y el receptor es el RLC de RNC objetivo.

A la vista de las consideraciones anteriores, es evidente que hay una necesidad de un sistema y procedimiento mejorados para realizar un procedimiento de reubicación de SRNS en un sistema de comunicaciones inalámbricas, y más específicamente de uno que resuelva eficientemente las discrepancias de descifrado que surgen entre las entidades de transmisión y de recepción como resultado de una inicialización que se realiza durante el procedimiento de Reubicación.

El documento ETSI TS 123 060 V4.3.0 (2002.–01). “Digital cellular telecommunications system (Phase 2+) (GSM)”. XP–002406009 da a conocer unos Procedimientos de Reubicación de RNS de servicio, en el que el RNC fuente decide realizar el Procedimiento de Reubicación de RNS de servicio. Cuando el SRNS cambia, el RNS antiguo o fuente reenvía todas las PDU de GTP de enlace descendente que se reciben y que no se han transferido aún al RNS objetivo. Estas PDU que se reenvían al RNS objetivo indican un número de secuencia de PDCP si las PDU de red contenidas se enviaron al equipo de usuario como SDU de PDCP, pero no se había dado aún un acuse de recibo. El RNS objetivo y el equipo de usuario intercambian número de secuencia respectivo de la siguiente PDU de PDCP esperada.

El documento ETSI TS 125 303 V3.9.0 (2001–09), “Universal Mobile telecommunications system (UMTS); Interlayer procedures in connected mode”, XP 014008610 ISSN: 00000–0001 da a conocer un procedimiento de reubicación de SRNS que puede dividirse en dos fases, es decir en una primera fase que es una preparación de reubicación y una segunda fase que es la transferencia del SRNS desde un RNC fuente hasta un RNC objetivo. Durante la segunda fase del procedimiento de Reubicación, si se ha iniciado un traspaso definitivo y reubicación de SRNS combinados por el SRNC fuente, el RNC fuente activa la ejecución de la reubicación de SRNS enviando un mensaje de RRC al equipo de usuario. Los valores de HFN de enlace descendente y de enlace ascendente actuales para la portadora de radio de señalización se transfieren a continuación desde el RNC fuente hasta el objetivo. A continuación, se restablece la entidad de RLC para la portadora de radio de señalización dedicada de modo con acuse de recibo, tanto en el lado de SRNC objetivo como en el del equipo de usuario, y los valores de HFN se ajustan a los valores de HFN de enlace descendente y de enlace ascendente actuales aumentados en uno.

Sumario de la invención

El objeto de la presente invención es proporcionar un procedimiento y sistema para realizar un procedimiento de reubicación de SRNS en un sistema de comunicaciones inalámbricas que aumenta la eficiencia de transmisión resolviendo eficientemente las discrepancias de descifrado que surgen entre las entidades de transmisión y de recepción cuando se realiza una etapa de inicialización en el procedimiento de Reubicación.

El presente objeto se consigue mediante la invención tal como se define en las reivindicaciones independientes 1 y

7.

La entidad de transmisión puede ser un RNC de UTRAN y la entidad de recepción puede ser un terminal de usuario, que por lo demás se conoce como equipo de usuario en las normas desarrolladas por el 3GPP, que incluye pero que no se limita al sistema de telecomunicaciones móviles universal (UMTS) que es una forma del sistema IMT–2000. Además, la entidad de transmisión puede ser el terminal de usuario y la entidad de recepción puede ser un RNC de UTRAN. La presente invención es también ventajosa debido a que ésta puede aplicarse a los modos UM y AM del funcionamiento de RLC.

La presente invención puede realizarse en un sistema de comunicación móvil, y más específicamente en un subsistema de red radio de servicio que incluye un controlador de red radio para gestionar un recurso de radio que se asigna a un terminal en el sistema de comunicación móvil. En este caso, el procedimiento de Reubicación incluye reservar un recurso de requisito en una reubicación de subsistema de red radio de servicio en una red; transmitir un mensaje de control de recursos de radio que se corresponde con la reubicación de subsistema de red radio de servicio al terminal a fin de que el controlador de red radio se comunique con el terminal, y transmitir un mensaje de control de recursos de radio de respuesta que se corresponde con la reubicación de subsistema de red radio de servicio al controlador de red radio al que se transmite el mensaje de control de recursos de radio.

El controlador de red radio transmite datos estableciendo una capa de enlace de radio correspondiente y ajustando un número de trama que se usa para el cifrado de tal modo que el terminal con éxito restaura los datos cifrados antes de que el controlador de red radio transmita el mensaje de control de recursos de radio correspondiente al terminal. El número de trama se aumenta en 1 más que un valor que se usa en el momento actual, y unos datos de unidad de la capa de enlace de radio correspondiente se transmiten mediante cifrado. Una capa de control de recursos de radio puede transmitir una instrucción para el establecimiento de una capa de control de enlace y el número de trama a la capa de control de enlace de radio correspondiente.

Además de estas etapas, un controlador de red radio original puede realizar el papel de un RNC de servicio antes de que la reubicación de subsistema de red radio de servicio transfiera la información de estatus de una capa de control de enlace de radio que se usa en el momento actual a un controlador de red radio objetivo. Esto se realiza de tal modo que el terminal recibe con éxito un mensaje de control de recursos de radio de servicio antes de que el controlador de red radio objetivo transmita un mensaje de control de recursos de radio que se corresponde con la reubicación de subsistema de red radio de servicio al terminal. La información de estatus transferida puede incluir un

parámetro que se corresponde con la capa de control de enlace de radio que se hace funcionar en un modo sin acuse de recibo. Asimismo, un primer número de secuencia de unos datos de unidad de la capa de control de enlace de radio que incluye el mensaje de control de recursos de radio que se corresponde con la reubicación de subsistema de red radio de servicio que se transfiere desde el controlador de red radio objetivo hasta el terminal se transmite ajustándose con una VT(US) de un parámetro que se corresponde con la capa de control de enlace de radio que se hace funcionar en el modo sin acuse de recibo.

La información de estatus transferida incluye un parámetro o datos que se corresponde con la capa de control de enlace de radio que se hace funcionar en un modo con acuse de recibo. Asimismo, un primer número de secuencia de datos de unidad de la capa de control de enlace de radio que incluye el mensaje de control de recursos de radio que se corresponde con la reubicación de subsistema de red radio de servicio que se transfiere desde el controlador de red radio objetivo hasta el terminal se transmite ajustándose con una VT(US) de un parámetro que se corresponde con la capa de control de enlace de radio que se hace funcionar en el modo sin acuse de recibo. La capa de control de enlace de radio del controlador de red radio objetivo puede transmitir unos datos de unidad de la capa de control de enlace de radio que se está transmitiendo que se transfieren a partir del controlador de red radio original.

El controlador de red radio original finaliza la transmisión del mensaje de control de recursos de radio que se está transmitiendo o que está esperando para su transmisión antes de transferir un parámetro que se corresponde con la capa de control de enlace de radio que se hace funcionar en el modo con acuse de recibo.

La capa de control de enlace de radio del controlador de red radio objetivo transmite una instrucción de movimiento de ventana de recepción a una capa de control de enlace de radio del terminal con el fin de evitar una transmisión de unos datos de unidad de la capa de control de enlace de radio que tiene un número de secuencia inferior a un número de secuencia de VT(S)–1. La capa de control de recursos de radio del controlador de red radio objetivo indica la capa de control de enlace de radio para iniciar la instrucción de movimiento de ventana de recepción con el fin de transmitir la instrucción de movimiento de ventana de recepción.

Tal como se describe anteriormente, la capa de control de recursos de radio transfiere el parámetro o los datos que se transfiere desde el controlador de red radio original hasta la capa de control de enlace de radio. Asimismo, un valor de un campo de un indicador de longitud de los datos de unidad de una primera capa de control de enlace de radio que incluye el mensaje de control de recursos de radio que se transmiten desde el controlador de red radio objetivo hasta el terminal después de la reubicación de subsistema de red radio de servicio indica una información de que los datos de unidad del control de enlace de radio correspondiente incluyen el mensaje de control de recursos de radio a partir de una primera parte de la misma.

Además, la presente invención puede usarse junto con una etapa de inicialización para la capa de control de enlace de radio, en la que se inicializa una variable de Estatus y se sincroniza un número de trama entre la capa de control de enlace de radio del terminal y la capa de control de enlace de radio del controlador de red radio objetivo. Esto permitirá que el terminal reciba con éxito el mensaje de control de recursos de radio antes de que el controlador de red radio objetivo transmita el mensaje de control de recursos de radio que se corresponde con la reubicación de subsistema de red radio de servicio al terminal. El controlador de red radio objetivo puede transmitir unos datos de unidad iniciales hasta la capa de control de enlace de radio del terminal como una instrucción que realiza una inicialización del control de enlace de radio.

Además, la capa de control de recursos de radio del controlador de red radio objetivo puede transferir una instrucción de inicio de inicialización hasta la capa de control de enlace de radio a fin de que la capa de control de enlace de radio del controlador de radio objetivo se inicie en un proceso de inicialización de la capa de control de enlace de radio.

Las capas de control de enlace de radio del controlador de red radio objetivo y el terminal se ajustan preferentemente con el fin de permitir que el controlador de red radio objetivo reciba con éxito el mensaje de control de recursos de radio correspondiente antes de que el terminal transmita el mensaje de control de recursos de radio que se corresponde con la reubicación de subsistema de red radio de servicio para el controlador de red radio objetivo. En este caso, un número de trama puede sincronizarse durante el establecimiento de las capas de control de enlace de radio del controlador de red radio objetivo y el terminal. Un establecimiento del número de trama puede transferirse a partir de una capa superior, y puede realizarse aumentando el número de tramas que se usa en el terminal y el controlador de red radio objetivo en 1 (uno). Alternativamente, el establecimiento del número de tramas que se usa en la capa de control de enlace de radio del terminal y en la capa de control de enlace de radio del controlador de red radio objetivo puede realizarse aumentando un valor más grande entre un número de trama de enlace ascendente y un número de trama de enlace descendente que se usa en la capa de control de enlace de radio del terminal y en la capa de control de enlace de radio del controlador de red radio objetivo en 1 (uno) en base al valor más grande.

La capa de control de recursos de radios del terminal y el controlador de red radio objetivo transmiten una instrucción respectiva para un establecimiento/ restablecimiento de las capas de control de enlace de radio correspondientes.

Un establecimiento/ restablecimiento de una portadora de radio de señalización y de una portadora de radio en el terminal y el controlador de red radio objetivo se realizan después de que un proceso en el que el terminal transmite un mensaje de control de recursos de radio de respuesta que se corresponde con la reubicación de subsistema de red radio de servicio al controlador de red radio objetivo. En este caso, un número de trama en el establecimiento/ restablecimiento de la portadora de radio de señalización y la portadora de radio entre el terminal y el controlador de red radio objetivo se ajusta a un valor inicial de número de trama que se incluye en el mensaje de control de recursos de radio de respuesta que se corresponde con la reubicación de subsistema de red radio de servicio que se transmite desde el terminal hasta el controlador de red radio objetivo. El valor inicial de número de trama que se incluye en el mensaje de control de recursos de radio puede corresponderse con un valor inicial que se almacena en un módulo de cifrado del terminal que se define en una norma de sistema de telecomunicaciones móviles universal de un sistema de IMT2000 asíncrono.

Ventajas, objetos, y características adicionales de la invención se expondrán en parte en la descripción que sigue y en parte serán evidentes para los expertos en la técnica tras el examen de lo siguiente o pueden aprenderse a partir de la práctica de la invención. Los objetos y ventajas de la invención pueden realizarse y obtenerse tal como se indica particularmente en las reivindicaciones adjuntas.

Breve descripción de los dibujos

La invención se describirá en detalle con referencia a los siguientes dibujos en los que números de referencia similares hacen referencia a elementos similares, en la que:

la figura 1 muestra una arquitectura de red de un sistema de telecomunicaciones móviles universal (UMTS); la figura 2 muestra una estructura de un protocolo de interfaz de radio que puede implementarse dentro del sistema UMTS; la figura 3 muestra una estructura de una unidad de datos de protocolo (PDU) que se usa en una capa de Control de Enlace de Radio (RLC) del protocolo de interfaz de radio de la figura 2; la figura 4 es una imagen a modo de ejemplo del estado de una memoria intermedia de RLC de AM; la figura 5 es un diagrama que ilustra el concepto de un Procedimiento de Reubicación de SRNS; la figura 6 es un procedimiento de señalización de Reubicación de SRNS en un sistema UMTS; la figura 7 es un procedimiento de señalización de Reubicación de SRNS de un sistema de la técnica relacionada que incluye una red de acceso de radio terrestre de UMTS (UTRAN); la figura 8 muestra un proceso de cifrado que se realiza en el protocolo de interfaz de radio de la figura 2; la figura 9 es la estructura del parámetro CONTEO–C que se usa dentro del modo de RLC; la figura 10 es un diagrama de flujo que muestra unas etapas incluidas en una serie de realizaciones del procedimiento de la presente invención que se identifican como A1 y A2 para realizar un procedimiento de reubicación de SRNS; la figura 11 es un diagrama de flujo que muestra unas etapas incluidas en una serie de realizaciones del procedimiento de la presente invención que se identifican como B1 y B2 para realizar un procedimiento de reubicación de SRNS; la figura 12 es un diagrama de flujo que muestra unas etapas incluidas en una serie de realizaciones del procedimiento de la presente invención que se identifican como C1, C2, y C3 para realizar un procedimiento de reubicación de SRNS; la figura 13 es un diagrama de flujo que muestra unas etapas incluidas en una realización del procedimiento de la presente invención que realiza una reubicación de SRNS para el caso de unas portadoras de radio sin pérdida; y la figura 14 es un diagrama de flujo que muestra unas etapas incluidas en una realización del procedimiento de la presente invención que realiza una reubicación de SRNS para el caso de unas portadoras de radio sin discontinuidades.

Descripción detallada de las realizaciones preferidas

La presente invención es un sistema y procedimiento para realizar un procedimiento de reubicación de SRNS en un sistema de comunicaciones inalámbricas. El procedimiento de Reubicación se realiza de una forma que evita que surja una condición sin sincronización entre las entidades de transmisión y de recepción. En una realización, la invención sincroniza la información de cifrado en las entidades de transmisión y de recepción. Tomando estas etapas, la presente invención mejora la fiabilidad y la eficiencia de las comunicaciones en el sistema. Mientras que la invención es adecuada para su uso en un sistema UMTS, los expertos en la técnica pueden apreciar que el procedimiento puede realizarse en unos sistemas de comunicaciones que sigan otras normas y/o protocolos.

El procedimiento de la presente invención controla la forma en la que información se transmite entre un receptor y un transmisor, y está especialmente bien adaptada para su uso en la aplicación no limitante en la que el transmisor es una UTRAN y el receptor es un terminal de usuario (o un equipo de usuario tal como se denomina por la iniciativa 3GPP). Cuando se aplica de esta forma, las etapas del procedimiento pueden diferir dependiendo del tipo de reubicación de SRNS que va a realizarse y el modo de funcionamiento de las capas de RLC de la UTRAN y del terminal de usuario.

El procedimiento de reubicación de SRNS puede clasificarse en dos casos. En el Caso I, la reubicación de SRNS se inicia por la red medular u otra red y no se informa al terminal de que se realiza la reubicación hasta que ha terminado el procedimiento de Reubicación. El caso I puede por lo tanto caracterizarse tal como correspondiéndose con la situación en la que el terminal no está involucrado en la realización de la decisión para realizar la reubicación. En el Caso II, la reubicación de SRNS se inicia por el terminal de usuario. El terminal es por lo tanto consciente de que la reubicación se está realizando en el mismo inicio del procedimiento. El caso II puede por lo tanto caracterizarse tal como correspondiéndose con la situación en la que el terminal está involucrado en la realización de la decisión para realizar la reubicación de SRNS.

Las diversas realizaciones del procedimiento de la presente invención pueden entenderse inicialmente distinguiendo éstas con respecto al procedimiento de la técnica relacionada de la figura 7. Mientras que la presente invención puede compartir alguna de las etapas en el procedimiento de la técnica relacionada, la siguiente discusión hace evidente que la presente invención supera ventajosamente los problemas de sincronización y otros que surgen en este sistema. Por lo tanto, una descripción del sistema de la técnica relacionada se proporcionará inicialmente.

Haciendo referencia a la figura 7, una etapa inicial del procedimiento difiere dependiendo de si el procedimiento de reubicación de SRNS se solicita por la red (Caso I) o por el terminal de usuario (Caso II). En el Caso I, el procedimiento de la presente invención se inicia cuando la red decide realizar una reubicación de SRNS, es decir, cuando la UTRAN decide conmutarse desde un RNS (o un RNC fuente) hasta otro RNS (o un RNC objetivo) con fines de comunicación con el terminal de usuario. (Etapa 2). La red puede decidir realizar una reubicación de SRNS en base a uno cualquiera de una variedad de factores. Por ejemplo, la reubicación puede ser deseable para reducir la cantidad de tráfico que se está manejando por el RNC fuente, para ubicar un trayecto de comunicaciones más corto o más eficiente con fines de manejar una llamada con el terminal de usuario, u otros motivos que pueden entenderse por los expertos en la técnica.

En el Caso II, el procedimiento de la presente invención se inicia cuando el terminal de usuario transmite un mensaje de RRC en la forma de un mensaje de Actualización de URA/ Célula para el RNC fuente. (Etapa 1). Este mensaje incluye una solicitud para cambiar el SRNS de la UTRAN. Un mensaje de este tipo puede transmitirse, por ejemplo, cuando el terminal de usuario se desplaza a una célula nueva dentro del sistema inalámbrico, por ejemplo, cuando se requiere o es inminente una operación de traspaso. En este momento, la red puede decidir si responder de forma favorable satisfaciendo la solicitud o puede responder inmediatamente.

Las etapas de la segunda a la quinta se realizan habitualmente para los Casos I y II. En la segunda etapa, se realiza la preparación de la reubicación. (Etapa 3). Esto implica el reenvío de parámetros relevantes para la comunicación con el terminal de usuario desde el RNC fuente hasta el RNC objetivo a través de un contenedor de información de RRC. Este contenedor incluye, por ejemplo, una información de cifrado (por ejemplo, unos de parámetros de HFN de enlace descendente y de HFN de enlace ascendente) para las portadoras de radio de señalización, así como unos recursos de radio que incluyen unas RAB nuevas con fines de cambiar el RNS de servicio desde el RNC fuente hasta el RNC objetivo. El tipo de portadoras de radio que se reservan en esta etapa depende de si se está soportando un modo de RLC de AM o de UM en la UTRAN. Si se soporta un modo AM, se reservan una o más portadoras de radio sin pérdida de tal modo que puede realizarse una reubicación de SRNS sin pérdida. Si se soporta un modo UM, se reservan una o más portadoras de radio sin discontinuidades de tal modo que puede realizarse una reubicación de SRNS sin discontinuidades.

La tercera etapa incluye recibir una Instrucción de Reubicación de RANAP a partir de la red medular, y más específicamente a partir de un SGSN que existe en la red medular. (Etapa 4). El SGSN que existe puede ser aquél al que se hace referencia como el “SGSN antiguo”, y si la reubicación da como resultado requerir un cambio de los SGSN (que puede no ser siempre el caso) un “SGSN nuevo” se asignará después de la reubicación. La Instrucción de Reubicación informa al RNC fuente de las RAB que van a liberarse y de las RAB que están sujetas a un reenvío de datos en conexión con el procedimiento de Reubicación. Un SRNC sin pérdida (que se realiza para un RLC de funcionamiento de AM) puede configurarse para las RAB sometidas a un reenvío de datos. La capa de PDCP soporta una numeración de secuencia de PDCP cuando se soporta una reubicación de SRNS sin pérdida.

La cuarta etapa incluye transmitir un mensaje de Compromiso de Reubicación desde el RNC fuente hasta el RNC objetivo. (Etapa 5). En esta etapa, para las portadoras de radio afectadas, el RLC fuente se detiene y los números de secuencia de transmisión de PDCP se recuperan por el RRC. El PDCP del RNC fuente transfiere los números de secuencia y otra información para la comunicación con el terminal de usuario al RNC objetivo.

La quinta etapa incluye transmitir un mensaje de Detección de Reubicación RANAP desde el RNC objetivo hasta el RNC fuente. (Etapa 6). Cuando este mensaje se recibe, el RNC objetivo se hace el RNC de servicio. Un cambio correspondiente desde el SGSN antiguo hasta el SGSN nuevo puede realizarse en este momento. Después de estas etapas, se ha producido la reubicación.

La sexta etapa incluye transmitir un mensaje de RRC desde el RNC objetivo hasta el terminal de usuario, y más específicamente hasta la capa de RRC del terminal de usuario. En el Caso I, el mensaje de RRC se encuentra en la forma de un mensaje de Información de Movilidad de UTRAN. En el Caso II, el mensaje de RRC se encuentra en la forma de un mensaje de Confirmación de Actualización de URA/ Célula. En cada uno de estos mensajes, una U–

RNTI nueva se incluye para informar al terminal de usuario de que se realizó un procedimiento de reubicación de SRNS.

Una séptima etapa incluye calcular un valor de INICIO en el terminal de usuario en respuesta a una información de sincronización de contador de enlace descendente. El valor de INICIO se transmite a continuación desde el terminal de usuario a la capa de RRC del RNC objetivo en un mensaje de RRC que se denomina mensaje de Confirmación de Información de Movilidad de UTRAN. (Etapa 7).

Una octava etapa incluye establecer unas entidades de RLC en el RNC objetivo en base al valor de INICIO que se incluye en el mensaje de Confirmación de Información de Movilidad de UTRAN. Entre tanto, el terminal de usuario puede restablecer también sus entidades de RLC con el valor de INICIO transmitido. (Etapa 8).

La descripción anterior puede servir como un marco para el enfoque que toma el procedimiento de la presente invención para superar el problema de falta de sincronización que afecta de forma perjudicial al rendimiento del procedimiento de la técnica relacionada de la figura 7. Este problema tiene lugar en la sexta etapa que se discute anteriormente.

En esta etapa, el RNC objetivo transmite un mensaje de RRC o bien en la SRB1 o bien en la SRB2 dependiendo del caso y del modo de funcionamiento de las entidades de RLC. Más específicamente, o bien un mensaje de Información de Movilidad de UTRAN se envía sobre un AM/ DCCH (SRB2) o sobre un UM/ DCCH (SRB1), o bien un mensaje de Confirmación de Actualización de URA/ Célula se envía sobre un UM/ DCCH (SRB1). A pesar de que el mensaje de Confirmación de Actualización de URA/ Célula puede usar un UM/ CCCH (SRB0), la política de reubicación de SRNS (si el SRNS se reubica antes de que se envíe la confirmación de Actualización de URA/ Célula, un DCCH ha de usarse para permitir el cifrado de los contenidos del mensaje) puede requerir que este mensaje no deba usar la SRB0 en el caso de una reubicación de SRNS.

Cuando se realizan las etapas que se muestran en la figura 7, surgen unos problemas de falta de sincronización entre el terminal de usuario y la UTRAN que evitan que se realicen las comunicaciones. Algunos de estos problemas tienen lugar tal como sigue.

Problema 1: Se envía un Mensaje de RRC de CL en la SRB1 (UM/ DCCH). Antes de la reubicación de SRNS, el RNC fuente puede estar comunicando unas PDU con el terminal de usuario en base a una información de descifrado sincronizada. Por ejemplo, el RNC fuente puede transmitir unas PDU en base a un parámetro de HFN de enlace descendente = X y un número de secuencia de transmisión que se corresponde con una variable de estado VT(US) = 50 para el modo UM de funcionamiento. De forma similar, el terminal de usuario puede transmitir unas PDU en base a un enlace ascendente HFN = X y una VR(US) = 50. Debido a que la información de descifrado y los números de secuencia de transmisión se sincronizan, el terminal de usuario y el RNC fuente pueden comunicarse sin problemas. No obstante, cuando tiene lugar la reubicación de SRNS, debido a que el valor de HFN se transfiere desde el RNC fuente hasta el objetivo sin ninguna información adicional (por ejemplo, sin una información de número de secuencia de transmisión en la forma de una o más de las variables de estado VT(US) o VR(US)), el RNC objetivo establece una entidad de RLC de UM con la misma información de descifrado que se usa por el RNC fuente (es decir, HFN de DL = X) pero con la variable de estado VT(US) ajustada a un valor recién inicializado, por ejemplo, cero.

Por consiguiente, cuando el RNC objetivo envía un mensaje de RRC al terminal de usuario, el terminal de usuario reconocerá en la mayoría de los casos el número de secuencia de transmisión en el mensaje de RRC tal como correspondiéndose con un número fuera de la secuencia, debido a que éste no incluye el número de secuencia que sigue a la última PDU que se transmite por el RNC fuente. Cuando esto tiene lugar (por ejemplo, cuando el terminal de usuario detecta que el mensaje de RRC recibido tiene un número de serie SN = 0), éste concluirá que una PDU nueva se ha recibido y más específicamente que unas PDU que tienen unos números de serie de entre 50 y 127 se han perdido. Como resultado, el terminal de usuario aumentará su HFN a un valor de X + 1 con fines de descifrado de las PDU futuras. No obstante, el RNC objetivo continuará transmitiendo las PDU en base a HFN = X. Debido a que hay una discrepancia en la información de descifrado que se usa por el terminal de usuario y el RNC objetivo, el terminal de usuario no será capaz de descifrar y por lo tanto de recibir con éxito las PDU que se transmiten desde el RNC objetivo. Esto significa que el terminal de usuario no puede recibir el mensaje de RRC.

Problema 2: Se envía un Mensaje de RRC de DL en la SRB2 (AM/ DCCH).

Antes de la reubicación de SRNS, supóngase que el HFN de DL = X y la VT(S) = 3.000 en el RNC fuente y que el HFN de DL = X y la VR(R) = 3.000 en el terminal de usuario. Debido a que la información de descifrado y los números de secuencia de transmisión se sincronizan, el terminal de usuario y el RNC fuente pueden comunicarse con éxito. No obstante, cuando tiene lugar la reubicación de SRNS, debido a que el valor de HFN se transfiere desde el RNC fuente hasta el RNC objetivo sin una VT(S) indicativa de un número de secuencia de transmisión, el RNC objetivo establecerá una entidad de RLC de AM con un HFN de DL = X pero con una VT(S) ajustada a un valor inicial, por ejemplo, VT(S) = 0.

Cuando el mensaje de RRC se envía desde el RNC objetivo hasta el terminal de usuario, el terminal de usuario descartará el mensaje si su número de secuencia de transmisión (que es cero en este caso) se encuentra fuera del

intervalo de la ventana de recepción. No obstante, incluso si el número de secuencia del mensaje de RRC se encuentra dentro de la ventana de recepción, el terminal de usuario considerará que éste es una PDU nueva, es decir, que unas PDU que tienen unos números de secuencia desde 3.000 hasta 4.095 se han perdido. Cuando esto tiene lugar, el terminal de usuario ajusta su HFN = X + 1. Como resultado, la información de descifrado en el terminal de usuario y en el RNC objetivo son diferentes y por lo tanto el terminal de usuario no será capaz de recibir el mensaje de RRC que se transmite desde el RNC objetivo.

En ambos problemas que se discuten anteriormente (SRB1 o SRB2), el terminal de usuario en la mayoría de los casos no puede recibir el mensaje de RRC que se transmite desde el RNC objetivo. Como resultado, falla la reubicación de SRNS. Por supuesto, se observa que hay una pequeña posibilidad de que el terminal de usuario sea capaz de recibir el mensaje de RRC inicial desde el RNC objetivo, si bien esto puede ocurrir sólo cuando VT(US) = VR(US) = 0 o VT(S) = VR(R) = 0. No obstante, incluso si el mensaje de RRC inicial desde el RNC objetivo se recibe con éxito y se descifra por el terminal de usuario, el RNC objetivo no será capaz de recibir el mensaje de RRC de Confirmación de Información de Movilidad de UTAN que se transmite a partir del terminal de usuario. Este mensaje se envía sobre el AM/ DCCH (SRB2), y no puede recibirse por el RNC objetivo debido a que VT (S) = 3.000 en el terminal de usuario pero VR(R) = 0 en el RNC objetivo.

El sistema y procedimiento de la presente invención supera estos y otros problemas que surgen en el sistema de la técnica relacionada como resultado de la sincronización y de las faltas de correspondencia de número de secuencia de transmisión. Tal como reflejarán las siguientes realizaciones, el RNC objetivo y el terminal de usuario se controlarán para sincronizar toda la información que se requiere a fin de que se realice un Procedimiento de Reubicación con éxito. Las realizaciones específicas se analizarán a continuación.

El procedimiento de la presente invención puede realizarse de forma diferente dependiendo de si se aplica el Caso I

o el Caso II. Cuando se solicita una reubicación de SRNS por la red (Caso I), la sexta etapa incluye una información de cifrado de sincronización en el RNC objetivo para la información de cifrado que se espera que se use en el terminal de usuario. Esta sincronización puede realizarse a la vista de la siguiente realización.

Durante el procedimiento de Reubicación, las PDU de RLC que se transmiten desde el RNC objetivo hasta el terminal de usuario tendrán unos valores inicializados. Por ejemplo, se dará a la primera PDU que se transmite un número de secuencia de transmisión inicial tal como cero. En el lado de terminal de usuario, la capa de RLC recibe unas PDU y las ordena en base a un número de secuencia de transmisión. Debido a que el terminal de usuario estaba comunicándose con el RNC fuente antes de la reubicación, la siguiente PDU que el RLC del terminal de usuario esperará recibir es una cuyo número de secuencia de transmisión sigue de forma consecutiva el número de secuencia de transmisión de la última PDU recibida. La primera PDU que se transmite desde el RNC objetivo en la UTRAN, no obstante, tendrá un número de secuencia inicializado y por lo tanto con toda probabilidad no se corresponderá con el número esperado.

Cuando esto tiene lugar una vez o un número predeterminado de veces, el RLC de terminal de usuario concluirá que se ha producido una condición de desbordamiento. Cuando se detecta una condición de este tipo, el RLC del terminal de usuario ajustará su información de descifrado cambiando su parámetro de HFN a un nuevo valor. Este cambio puede implicar aumentar el parámetro de HFN en 1.

En el procedimiento de la técnica relacionada de la figura 7, el RNC objetivo no compensó este cambio en la información de descifrado en el terminal de usuario. En su lugar, se cifraron unas PDU usando una información de cifrado (es decir, el parámetro de HFN) que se incluye en el contenedor de información de RRC enviado desde el RNC fuente hasta el RNC objetivo. Como resultado, las PDU que se transmitieron desde el RNC objetivo no pudieron descifrarse por el terminal de usuario y se produjo una caída en las comunicaciones.

La presente invención supera este problema tomando uno de varios enfoques. Un enfoque implica ajustar la información de cifrado en el RNC objetivo que se recibe desde el RNC fuente. Este ajuste garantiza que el RNC objetivo cifra unas PDU con el mismo parámetro de HFN que el terminal de usuario usará durante el descifrado. Debido a que el software de gestión de UTRAN se programa para conocer cómo el terminal de usuario ajustará su parámetro de HFN cuando se recibe una PDU que tiene un número de secuencia de transmisión fuera de secuencia, el RNC objetivo puede cifrar las PDU que van a enviarse al terminal de usuario que usa el mismo parámetro de HFN ajustado. La naturaleza del ajuste que se realiza mediante la presente invención depende de si está observándose el Caso I o el II y si los RLC del terminal de usuario y los RNC objetivo están funcionando en el modo AM o UM. Se aplican las siguientes situaciones.

A. Mensaje de RRC de Enlace descendente Enviado en la SRB1 (UM/ DCCH).

En este caso, los RLC del RNC objetivo y el terminal de usuario están funcionando en el modo UM. El RNC objetivo envía un mensaje de RRC sobre una portadora de radio de servicio SRB1 (que se corresponde con un canal DCCH de UM) al terminal de usuario. Se aplican las siguientes situaciones.

A.1. El RNC objetivo Establece una SRB1 y Aumenta el HFN de DL.

Haciendo referencia a la figura 10, el RNC objetivo recibe un contenedor de información de RRC desde el RNC

fuente. El contenedor incluye una información de cifrado que incluye preferentemente un parámetro de HFN que el RNC fuente estaba usando para comunicarse con el terminal de usuario. Cuando se recibe el contenedor de información de RRC, el RNC objetivo aumenta el parámetro de HFN y establece una nueva SRB1. Debido a que el RNC objetivo tiene un conocimiento previo de la forma en la que el terminal de usuario cambia su parámetro de HFN cuando una condición de desbordamiento tiene lugar o cuando se recibe una PDU fuera de secuencia, el RNC objetivo aumenta su parámetro de HFN de una forma idéntica. Como resultado, las PDU que se generan por el RNC objetivo se cifrarán de una forma que puede descifrarse por el terminal de usuario.

Una vez que se han generado las PDU, éstas se transmiten desde un RLC de UM del RNC objetivo hasta el terminal de usuario. La primera PDU que se transmite incluye un número de secuencia de transmisión inicial, por ejemplo, SN = 0. Cuando el terminal de usuario recibe las PDU, el terminal de usuario detecta que la primera PDU tiene un número de secuencia de transmisión fuera de secuencia. El terminal de usuario puede realizar esta función de detección extrayendo la variable de estado VR (US) de la primera PDU. Debido a que esta variable de estado proporciona una indicación del número de secuencia de transmisión que se corresponde con esta PDU, puede detectarse una condición de fuera de secuencia o desbordamiento. Por ejemplo, en el caso en el que la VR(US) tiene unos valores desde 0 hasta 127, el terminal de usuario puede determinar que unas PDU que tienen el valor de la VR(US) en la PDU recibida hasta el número de VR 127 se han perdido.

Cuando se detecta esta condición, el terminal de usuario ajustará su parámetro de HFN, por ejemplo, aumentando este parámetro en 1. Debido a que las PDU que se transmiten desde el RNC objetivo se generaron y se transmitieron de acuerdo con este mismo parámetro de HFN, pueden descifrarse las PDU y pueden tener lugar las comunicaciones a pesar del procedimiento de Reubicación. Sincronizando la información de cifrado en el terminal de usuario y en el RNC objetivo, la presente invención supera ventajosamente el problema de falta de sincronización que tiene lugar en el sistema de la técnica relacionada de la figura 7.

Una etapa opcional pero deseable implica incluir un indicador de inicio de datos (que puede ser al que se hace referencia como L1 Especial) en una o más PDU que se transmiten desde el RNC objetivo hasta el terminal de usuario. De acuerdo con la presente invención, el indicador de inicio de datos puede incorporarse en las PDU que se transmiten por el RNC objetivo a lo largo de un canal DCCH de UM. La inclusión de este indicador es ventajosa. Por ejemplo, si el terminal de usuario recibe una PDU desde el RNC objetivo sin el indicador de inicio de datos, el terminal de usuario puede considerar que la PDU es parte de una SDU anterior y puede simplemente descartar ésta. Cuando se recibe por el terminal de usuario, se interpretará el indicador de inicio de datos indica que la PDU a la que éste se acopla no es parte de una SDU anterior. La inclusión de este indicador garantizará por lo tanto que no se descartarán unas PDU que se reciben desde el RNC objetivo. Con el fin de maximizar la eficiencia de transmisión, la primera PDU que se transmite desde el RNC objetivo (es decir, la PDU que tiene un número de secuencia de transmisión SN = 0) incluye preferentemente el indicador L1 Especial.

A.2. El RNC fuente Transfiere la VT(US) al RNC objetivo.

Este enfoque difiere con respecto al enfoque en A. 1. en que en lugar de aumentar su parámetro de HFN, la primera PDU que se transmite desde el RNC objetivo hasta el terminal de usuario contiene el siguiente número de secuencia de transmisión que el terminal de usuario espera recibir. Por lo tanto, el parámetro de HFN que se usa por el RNC objetivo y el terminal de usuario permanece sincronizado y por lo tanto pueden realizarse unas comunicaciones de datos. Una descripción más detallada de este enfoque se proporcionará a continuación.

En una etapa inicial, el RNC fuente entrega un contenedor 50 de información de RRC que incluye una variable de estado VT(US) de una portadora de radio de servicio SRB1 al RNC objetivo. La variable de estado VT(US) es indicativa de un número de secuencia de transmisión que se relaciona con el número de secuencia de transmisión de la última o unas de las últimas PDU que se transmiten desde el RNC fuente hasta el terminal de usuario. El RNC objetivo usa la variable de estado VT(US) como una base para la transmisión de su primera PDU 60 al terminal de usuario. Por ejemplo, si la VT(US) se corresponde con el último número de secuencia transmitido, el RNC objetivo puede incrementar el número de secuencia de transmisión que se corresponde con la VT(US) en uno y a continuación transmitir la primera PDU que contiene este valor. Cuando el terminal de usuario recibe esta PDU, detectará que esta PDU tiene el siguiente número en la secuencia que éste esperaba y por lo tanto no se detectará una condición de PDU perdida o de desbordamiento. Como resultado, el terminal de usuario no aumentará su valor de HFN como en el caso anterior; y debido a que la PDU se cifró en base al mismo valor de HFN, el terminal de usuario será capaz de descifrarla.

Como una alternativa a este enfoque, la variable VT(US) que se entrega desde el RNC fuente hasta el RNC objetivo puede ser el siguiente número en la secuencia que el equipo de usuario espera recibir. En este caso, el RNC objetivo transmitirá la primera PDU con el número que se corresponde con la VT(US).

Este enfoque puede incluir un número de etapas adicionales. En primer lugar, puede usarse un nuevo IE (elemento de información) a la luz de la adición de VT(US) de SRB1 en el contenedor de información de RRC.

En segundo lugar, puede modificarse la etapa de establecimiento de RLC. Por ejemplo, se establece cuando la entidad de RLC, todas las variables de estado pueden ajustarse a unos valores iniciales (por ejemplo, 0). Como

resultado, puede no ser posible establecer la entidad de RLC de UM con una VT(US) diferente de 0. Con el fin de compensar el establecimiento de las variables de estado a los valores iniciales, debería de realizarse un procedimiento de establecimiento y modificación. Es decir, en primer lugar, se establece la entidad de RLC con todas las variables de estado siendo 0, en segundo lugar, las variables de estado se modifican para ser valores deseados.

En tercer lugar, un indicador de inicio de datos (por ejemplo, L1 de Inicio) debería incluirse en la primera PDU de UM que se transmite desde el RNC objetivo hasta el terminal de usuario. Si la primera PDU se transmite sin este indicador y si, por ejemplo, la PDU con número de secuencia SN = VT(US) - 1 se ha perdido, el equipo de usuario descartará la PDU. Debido a que el equipo de usuario considera que la PDU contiene una SDU incompleta, una parte de la cual puede estar contenida en la PDU anterior. Incluir el indicador de inicio de datos en la primera PDU que se transmite desde el RNC objetivo garantizará por lo tanto que el mensaje de RRC se recibirá por el terminal de usuario.

B. Mensaje de RRC de Enlace descendente Enviado en la SRB2 (AM/ DCCH).

En este caso, los RLC del RNC objetivo y el terminal de usuario están funcionando en el modo AM. El RNC objetivo envía un mensaje de RRC sobre una portadora de radio de servicio SRB2 (que se corresponde con un canal DCCH de AM) al terminal de usuario.

B.1. El RNC objetivo Establece una SRB2 e inicializa el Procedimiento de REAJUSTE de RLC.

Haciendo referencia a la figura 11, antes de enviar el mensaje de RRC, el RNC objetivo realiza una operación de REAJUSTE de RLC que implica el restablecimiento del número de secuencia de transmisión y de las variables de estado a los valores iniciales. Preferentemente al mismo tiempo, el RNC objetivo transmite una Reajustar 70 PDU al terminal de usuario. De acuerdo con un aspecto de la invención, la Reajustar PDU se transmite sin estar cifrada y no tiene un número de secuencia de transmisión. Por consecuencia, el terminal de usuario será capaz de recibir la Reajustar PDU que se transmite a través de la SRB2. Tras la recepción de la Reajustar PDU, el terminal de usuario reajustará sus variables de estado y número de secuencia de transmisión a los mismos valores iniciales que se ajustan en el RNC objetivo.

Debido a que la Reajustar PDU no tiene un número de secuencia de transmisión, el terminal de usuario no detectará un desbordamiento o condición de fuera de secuencia cuando se recibe la Reajustar PDU. Por lo tanto, no se aumentará el parámetro de HFN en el terminal de usuario. Como resultado, el parámetro de HFN que el RNC objetivo que se recibe desde el RNC fuente y el parámetro de HFN del terminal de usuario será el mismo. Y, debido a que las variables de estado y los números de secuencia de transmisión del RNC objetivo y el terminal de usuario se han inicializado a unos valores similares, el RNC objetivo y el terminal de usuario pueden comunicarse con éxito entre sí. Cuando se completa el reajuste en el terminal de usuario, un mensaje de reajustar acuse de recibo Reajustar 80 ACK de PDU se transmitirá desde el terminal de usuario al RNC objetivo.

Como una alternativa a la presente realización, la operación de Reajuste que se realiza en el RNC objetivo puede dar lugar a que se aumente el parámetro de HFN. La Reajustar PDU puede modificarse a continuación de tal modo que el terminal de usuario aumenta su valor de HFN tras la recepción. Esto puede llevarse a cabo, por ejemplo, transmitiendo la Reajustar PDU con un número de secuencia de transmisión inicial o fuera de secuencia.

Como resultado de las etapas anteriores, se sincronizarán los parámetros de HFN y los números de secuencia de transmisión del RNC objetivo y el terminal de usuario. Con el fin de conseguir esta sincronización, se prefiere pero no es necesario proporcionar una nueva activación para el Procedimiento de Reajuste de RLC. Más específicamente, en condiciones de funcionamiento normales se realiza un Procedimiento de Reajuste de RLC cuando se detecta un error de protocolo de RLC y/o cuando se detecta una de tres condiciones de activación que se especifican en la especificación de 3GPP. En la presente realización de la presente invención, el procedimiento de Reajuste puede realizarse cuando se detecta una cuarta condición de activación. Haciendo referencia a la especificación, se realiza un procedimiento de reajuste de RLC, si se detecta una de las siguientes activaciones.

1) se configura “No_Descarte después de un número de retransmisiones MaxDAT” y VT(DAT) es igual al valor MaxDAT; 2) VT(MRW) es igual al valor MaxMRW; 3) se recibe una PDU de ESTATUS que incluye “Número de secuencia erróneo”;

Más específicamente, de acuerdo con una realización alternativa de la presente invención, se usa una nueva C– primitiva (un mensaje de control desde el RRC hasta el RLC) y una nueva activación en el protocolo de RLC para iniciar el procedimiento de Reajuste.

Durante el procedimiento de Reajuste, puede realizarse al menos una etapa adicional. En esta etapa, todas las SDU de RLC en el terminal de usuario y en el RNC objetivo se ponen a nivel. A pesar de que la presente realización de la invención requiere algún tiempo para realizar y puede sufrir alguna pérdida de datos, ésta proporciona una clara solución para el problema de las contraseñas de cifrado no sincronizadas realizadas por el sistema de la técnica relacionada.

B.2. El RNC fuente Transfiere la VT(S) al RNC objetivo.

Haciendo referencia de nuevo a la figura 11, la presente realización de la invención es similar a la realización que se analiza anteriormente en el punto A.2, excepto en que un enfoque diferente se toma para tener en cuenta la ventana de recepción en el terminal de usuario y en el hecho de que las PDU de RLC se retransmiten en el modo de funcionamiento de AM. Por consiguiente, en lugar de ajustar el número de secuencia de la PDU de RLC que va a transmitirse al terminal y sincronizar el valor de HFN, puede requerirse que el RNC objetivo considere las unidades de datos que se transmitieron previamente al terminal por el RNC fuente que no se confirmaron por el terminal de usuario. Las siguientes etapas pueden tomarse para compensar este problema eventual.

En la etapa de proceso B.2.1., el RNC fuente transfiere un mensaje 90 que contiene una información que se relaciona con el establecimiento de la SRB2 al RNC objetivo. Esta información incluye el número de secuencia, la variable de estado VT(S), y el parámetro de HFN que se usa por la capa de RLC del RNC fuente, junto con una o más PDU de RLC o un mensaje de RRC que se está transmitiendo. En la etapa de proceso B. 2.2., el RNC objetivo transmite a continuación una o más PDU 100 que van a retransmitirse al terminal de usuario que usa la información que se transfiere desde el RNC fuente. Como resultado, el RNC objetivo transmitirá las PDU de la misma forma y con la misma información que el RNC fuente.

Como ejemplo, considérese el caso en el que el RNC fuente transmite su parámetro de HFN, una o más PDU de RLC que van a retransmitirse, la VT(S) que indica número de secuencia, y la VT(A) en la etapa B1 de la figura 11. El RNC objetivo almacena las PDU desde el RNC fuente después de configurar la capa de RLC con los parámetros recibidos (Etapa B.2.2 en la figura 11), y envía un mensaje de Información de Movilidad de UTRAN con una PDU nueva que comienza con el número de secuencia que se corresponde con la VT(S). Debido a que el RNC objetivo puede transmitir unos datos mientras que sostiene un estado de memoria intermedia de retransmisión de la SRB2 igual al estado de memoria intermedia de retransmisión del RNC fuente, el terminal de usuario puede recuperar los datos retransmitidos desde el RNC objetivo a través del canal de SRB2.

De acuerdo con otra realización, el RNC fuente entrega la VT(S) al RNC objetivo a través de un contenedor de información de RRC. El RNC objetivo establece a continuación una SRB2 (RLC de AM) con los valores transferidos y envía un mensaje de RRC al terminal de usuario con esos valores. El terminal de usuario funciona de una forma diferente en comparación con A.2. debido a que el RLC de AM del terminal recibe unas PDU que sólo se encuentran dentro de un intervalo válido de una ventana de recepción.

Si el número de secuencia de transmisión que se corresponde con la variable VT(S) es igual a VR(R), no se produce ningún problema. Pero si la VT(S) es más grande que la VR(R) (principalmente debido a las SDU de RLC sin confirmar en el RLC fuente), el terminal de usuario transmitirá una PDU de Estatus al RNC objetivo que indica que las PDU de AMD desde la VR(R) hasta la VT(S)–1 se han perdido. Si no se toma una acción apropiada, el siguiente problema puede tener lugar: debido a que VT(A) = VT(S), el RLC objetivo determina que la PDU de Estatus recibida contiene un “Número de secuencia erróneo” e iniciará un procedimiento de Reajuste. Las PDU de RLC que se transmiten antes de que se implemente el procedimiento de Reajuste se perderán (obsérvese que las memorias intermedias de RLC pueden ponerse a nivel durante el procedimiento de Reajuste).

Para garantizar una transmisión con éxito, la presente realización de la presente invención entrega la VT(A) además de la VT(S) desde el RNC fuente hasta el RNC objetivo. El RNC objetivo transmite a continuación las PDU en la SRB2 en base a la VT(A), la VT(S) y el parámetro de HFN que se transfiere desde el RNC fuente. Un procedimiento de establecimiento y modificación puede realizarse a continuación tal como se analizó en conexión con la realización de A.2. de la invención.

El mensaje de RRC se transmite por las PDU de AMD a partir de la VT(S). Si una PDU de Estatus que indica que el terminal de usuario no recibió las PDU desde la VR(R) hasta la VT(S)–1 se transmite desde el terminal al RNC objetivo, el RNC objetivo transmite un mensaje SUFI de MRW al terminal de usuario con el fin de desplazar la ventana de receptor hasta la VT(S). Con el fin de implementar estas características, puede usarse una activación adicional para la transmisión del mensaje SUFI de MRW. Por consecuencia, una nueva C–primitiva puede implementarse junto con una nueva activación para realizar un descarte de SDU con un procedimiento de señalización explícita.

De acuerdo con una realización alternativa, el RNC fuente entrega su valor de HFN y la VT(S) al RNC objetivo (Etapa B.2.1. en la figura 11), y detiene la transmisión de las PDU al terminal de usuario antes de la reubicación de SRNS. En el RLC del terminal, se completa el procesamiento de los mensajes de RRC anteriores. Por lo tanto, la primera PDU que se recibe después de que la reubicación de SRNS incluye el mensaje de Información de Movilidad de UTRAN que tiene el valor de VT(S).

De acuerdo con otra realización, el RNC fuente entrega su valor de HFN y la VT(S) al RNC objetivo (el proceso

B.2.1. en la figura 11). El RNC fuente transmite a continuación una instrucción al terminal de usuario para indicar a la capa de RLC del terminal de usuario que desplace su ventana de recepción y que no solicite los datos de retransmisión. La capa de RRC de la UTRAN puede usarse para indicar a la capa de RLC del RNC fuente que

transmita esta instrucción. Las etapas restantes del procedimiento son similares a la realización que se analiza inmediatamente antes, no obstante la presente realización puede implementarse para eliminar los mensajes de RRC antes de que el SRNS se reubique y para solucionar el problema de retransmisión.

En una cualquiera o más de las realizaciones B.2. que se analizan anteriormente, puede realizarse una etapa opcional de incluir un indicador de inicio de datos en la primera PDU que se transmite por el RNC objetivo al terminal de usuario. El indicador de inicio de datos puede ser del mismo tipo que se transmite en el mensaje de RRC que se transmite desde el RNC objetivo a pesar de la SRB1 de acuerdo con la realización que se analiza anteriormente.

El siguiente ejemplo es de aplicación: puede que la PDU de RLC que se corresponde con el número de secuencia de VT(S)–1 no se reciba correctamente. La siguiente PDU de RLC que se transmite por el RNC objetivo justo después de que se realiza el procedimiento de Reubicación puede incluir el indicador de inicio de datos

B.3. No enviar Información de Movilidad de UTRAN en la SRB2 en el Caso de SRNS

Reubicación. A partir de las realizaciones B.1. y B.2., es evidente que la transmisión de un mensaje de RRC en la SRB2 puede ser problemático en algunos aspectos. En esta realización de B.3, la realización de A.1 o de A.2 puede implementarse sin la transmisión de Información de Movilidad de UTRAN en la SRB2.

Las realizaciones que se discuten anteriormente se realizan todas preferentemente antes de o durante la transmisión de Información de Movilidad de UTRAN (Caso I) o de un mensaje de Confirmación de Actualización de URA/ Célula (Caso II). Es decir, uno u otro tipo de mensaje puede recibirse por el terminal de usuario cuando se realizan las realizaciones A y B de la invención. Incluso a pesar de que el terminal de usuario puede recibir mensajes de RRC de enlace descendente correctamente a partir de la UTRAN, pueden surgir ciertas situaciones que evitarán que el RNC objetivo reciba un mensaje de Confirmación de Información de Movilidad de UTRAN a partir del terminal de usuario en ambos Casos I y II. Este mensaje de confirmación puede enviarse en la SRB2 (AM/ DCCH), pero debido a que la VT(S) en el terminal de usuario y la VR (R) en el RNC objetivo son normalmente diferentes (por ejemplo, VT(S) f 0, VR(R) = 0) puede surgir una necesidad de sincronizar los valores de HFN y de SN en el terminal de usuario y en el RNC objetivo antes de que se transmita el mensaje de Confirmación de Información de Movilidad de UTRAN. Las siguientes realizaciones de la presente invención tratan este problema.

C.1. El terminal de usuario Recibe el Mensaje de RRC de Enlace descendente en la SRB1 (UM/ CCCH).

Haciendo referencia a la figura 12, en este caso sólo se sincroniza el HFN de enlace descendente de SRB1. Antes de la transmisión de un mensaje de RRC de enlace ascendente (es decir, un mensaje de RRC desde el terminal hasta el RNC objetivo), tanto el RNC objetivo como el terminal de usuario deberían de realizar las operaciones 110 y 120 que respectivamente establecen y restablecen la SRB2. Esto incluye el establecimiento tanto del RNC objetivo como del terminal de usuario al mismo valor de HFN. Estas etapas pueden llevarse a cabo cifrando un mensaje que se transmite desde el terminal de usuario al RNC objetivo con un valor de HFN aumentado (por ejemplo, el valor actual de HFN + 1) tal como se realiza en el caso de un Traspaso Definitivo y reubicación de SRNS combinados. Otro posible valor para el HFN es MAX(HFN de UL de la SRB2 | HFN de DL de la SRB2) + 1. Cualquier valor puede usarse siempre que el terminal de usuario y el RNC 31 objetivo tengan el mismo HFN.

C.2. El terminal de usuario Recibe el Mensaje de RRC de Enlace descendente en la SRB2 (AM/ DCCH) con un Procedimiento de REAJUSTE.

Si el terminal de usuario recibe un Mensaje de RRC de Enlace descendente en la SRB2 y se realiza la realización de B.1, la SRB2 no tiene que establecerse/ restablecerse después de que se recibe el mensaje. Durante el procedimiento de Reajuste, los valores de HFN en el terminal de usuario y en el RNC objetivo (los HFN de UL y de DL) se sincronizan y el terminal de usuario envía un mensaje de RRC de UL hasta el RRC objetivo sin restablecer la SRB2. Después de la transmisión del mensaje de RRC de UL, tanto el terminal de usuario como la UTRAN deberían de establecer/ restablecer las SRB (excepto la SRB2) y las RB con el valor de INICIO que se incluye en el mensaje de Confirmación de Información de Movilidad de UTRAN

C.3. El terminal de usuario Recibe el Mensaje de RRC de Enlace descendente en la SRB2 (AM/DCCH) con un descarte de SDU con un procedimiento de señalización explícita.

Si el terminal de usuario recibe un mensaje de RRC de DL en la SRB2 y se realiza la realización de B.2., sólo se sincroniza el HFN de DL de la SRB2. Debido a que el HFN de UL no se sincroniza, la SRB2 ha de establecerse/ restablecerse tanto en el terminal de usuario como en la UTRAN. El resto del procedimiento es el mismo que en el caso C.1. excepto en que la SRB1 de DL necesita restablecerse.

En una o más de las realizaciones de C que se analizan anteriormente, después de la transmisión del mensaje de RRC de UL, tanto el terminal de usuario como la UTRAN pueden restablecer/establecer las SRB (excepto la SRB2) y las RB con un valor de INICIO que se corresponde con un valor inicial del HFN. Esto puede llevarse a cabo transmitiendo el valor de INICIO en el mensaje de RRC, es decir, el mensaje de Confirmación de Información de Movilidad de UTRAN. Como ejemplo, el valor de INICIO puede almacenarse en los 20 bits superiores del HFN. Si el tamaño del HFN supera los 20 bits, los bits restantes pueden inicializarse a 0. El valor de INICIO puede

corresponderse con un valor predeterminado (que puede, por ejemplo, definirse de acuerdo con las normas desarrolladas por el 3GPP) y puede gestionarse por un módulo de cifrado del terminal. El valor de INICIO puede estar desconectado con respecto al terminal o puede actualizarse de acuerdo con un cambio en el valor de HFN durante la conexión.

Ha de observarse que la realización de C.1. puede aplicarse para todos los casos. A pesar de que el terminal de usuario recibe un mensaje de RRC de DL en la SRB2 con un Procedimiento de Reajuste en el caso de C.2, el restablecimiento de SRB2 no da lugar a problemas durante el funcionamiento normal. En este caso, los HFN pueden actualizarse un máximo de dos veces.

En las realizaciones anteriores, puede preferirse no incluir un IE (elemento de información) “indicador de restablecimiento de RLC (RB2, RB3, y RB4)” en el mensaje de Confirmación de Actualización de Célula. Si se incluye éste, el terminal de usuario puede restablecer la SRB2, la SRB3, y la SRB 4 y ajustar sus valores de HFN a un valor de INICIO que se incluye en el último mensaje de Actualización de Célula transmitido. Debido a que el terminal de usuario SRB2 se restablece con este valor de INICIO, la UTRAN puede no ser capaz de recibir un mensaje de Confirmación de Información de Movilidad de UTRAN (la SRB2 de UTRAN se establece con o bien HFN + 1 o bien MAX(HFN de UL de la SRB2 | HFN de DL de la SRB2) + 1). Se observa además que estas realizaciones pueden corresponderse con la totalidad de las SRB y de las RB comunes. No obstante, para la SRB2, debido a que el valor de HFN se sincroniza antes de que se transmita el mensaje de Confirmación de Información de Movilidad de UTRAN, puede no ser necesario reajustar el valor de HFN. Asimismo, mientras que el valor inicial para la VT (US) se ha analizado de forma ilustrativa tal como correspondiéndose con cero, los expertos en la técnica pueden apreciar que pueden usarse otros valores iniciales para esta o cualquier otra variable de estado que se analiza en el presente documento.

Las realizaciones de la presente invención se han adoptado en las siguientes Especificaciones Técnicas de 3GPP que se incorporan por referencia en el presente documento: la Especificación Técnica TS 25.303 v3.10.0, la Especificación Técnica TS 25.303 v3.11.0, la Especificación Técnica TS 25.322 v3.9.0, la Especificación Técnica TS

25.331 v3.9.0, la Especificación Técnica TS 25.331 v3.10.0, y todas las actualizaciones, revisiones, y modificaciones a las mismas.

Una forma de volver a expresar las diversas realizaciones de la invención tal como se indica anteriormente puede proporcionarse tal como sigue.

Actualización de URA/ Célula y Reubicación de SRNS Combinada (Portadoras de radio sin pérdida)

El procedimiento de la presente invención puede iniciarse al decidir realizar el RNC fuente una reubicación de SRNS. Las etapas de este procedimiento, que se han analizado anteriormente y que vuelven a expresarse a continuación, se muestran en mayor detalle en la figura 13. En este caso, el Caso 1 representa la situación en la que el equipo de usuario (UE) no está involucrado y el Caso 2 representa la situación en la que el UE está involucrado y se realiza una Actualización de URA/ Célula y reubicación de SRNS combinada.

En una etapa inicial, una Instrucción de Reubicación de RANAP se recibe por el RNC fuente a partir de la CN, que indica las RAB que van a liberarse y las RAB que están sujetas a reenvío de datos. Puede configurarse una reubicación de SRNS sin pérdida para las RAB que están sujetas a reenvío de datos. La capa de PDCP soporta una numeración de secuencia de PDCP cuando se soporta una reubicación de SRNS sin pérdida.

Para las portadoras de radio afectadas, se detiene la entidad de RLC y los números de secuencia de PDCP se recuperan por el RRC. Los números de secuencia de emisión y de recepción de PDCP se transfieren a continuación en el mensaje de Compromiso de Reubicación RNSAP desde el RNC fuente hasta el objetivo para las RAB que soportan una reubicación de SRNS sin pérdida. El RNC objetivo se hace el RNC de servicio cuando se envía el mensaje de Detección de Reubicación RANAP.

El RNC objetivo envía a continuación un mensaje de INFORMACIÓN de MOVILIDAD de UTRAN (Caso 1) en laSRB#1 (UM/ DCCH) o en la SRB#2 (AM/ DCCH), o un mensaje de CONFIRMACIÓN de ACTUALIZACIÓN de URA/ CÉLULA (Caso 2) en la SRB#1 (UM/ DCCH), que configura el UE con la U–RNTI nueva y que indica el número de secuencia de PDCP de recepción de enlace ascendente para cada portadora de radio configurada para soportar una reubicación de SRNS sin pérdida.

Si va a usarse la SRB#1, el RNC objetivo establece la entidad de RLC de UM para la SRB#1 y el HFN de DL y/o los valores VT(US) se ajustan a los valores en el contenedor de RRC. Al realizar esta etapa, el valor de HFN de DL puede ajustarse al valor de HFN de DL actual aumentado en uno. En la entidad de RLC de UM, un “L1 Especial” se usa preferentemente para indicar que una SDU de RLC se inicia en el inicio de una PDU de RLC.

Si va a usarse la SRB#2, el RNC objetivo establece la entidad de RLC de AM y los valores de HFN de DL y de UL se ajustan a los valores de HFN de DL y de UL actuales. Antes de enviar un mensaje de INFORMACIÓN de MOVILIDAD de UTRAN, el lado de transmisión de la entidad de RLC de AM inicia un procedimiento de REAJUSTE de RLC para sincronizar los valores de HFN entre la UTRAN y el UE.

Tras la recepción por el UE del mensaje, el UE compara el número de secuencia de PDCP de recepción de enlace ascendente con el número de secuencia de PDCP de envío de enlace ascendente de UE. Si esto confirma que las SDU de PDCP se transfirieron con éxito antes del inicio de la reubicación (es decir, ya se han recibido por el RNC fuente), a continuación éstas se descartan por el UE. El UE reinicializa las entidades de compresión de cabecera de PDCP de las portadoras de radio configuradas para usar un protocolo de compresión de cabecera. La entidad de RLC (por ejemplo, el RLC de AM) para la SRB#2 se (r)establece tanto en el lado de UTRAN como en el de UE, y sus valores de HFN se ajustan a un valor aumentado en uno. (En este caso, VALOR puede definirse como o bien el valor actual de HFN o MAX (HFN de UL de la SRB2 | HFN de DL de la SRB2)).

Si el UE se ha configurado con éxito a sí mismo, enviará un mensaje de CONFIRMACIÓN de INFORMACIÓN de MOVILIDAD de UTRAN (Caso 1 y Caso 2). Estos mensajes contienen preferentemente los valores de INICIO y el número de secuencia de PDCP de recepción de enlace descendente para cada portadora de radio configurada para soportar una reubicación de SRNS sin pérdida.

Tras la recepción y el acuse de recibo por la UTRAN del mensaje, la UTRAN compara el número de secuencia de PDCP de recepción de enlace descendente con el número de secuencia de PDCP de envío de enlace descendente. La UTRAN inicializa las entidades de compresión de cabecera de PDCP de las portadoras de radio configuradas para usar un protocolo de compresión de cabecera. Las entidades de RLC para las portadoras de radio afectadas (que no sean la SRB#2) se (r)establecen tanto en el lado de UTRAN como en el de UE. Los valores de HFN para cada RB se ajustan preferentemente al valor de INICIO en el mensaje para el dominio de CN correspondiente, y todas las memorias intermedias de datos se ponen a nivel.

En caso de fallo, el UE enviará un mensaje de FALLO de INFORMACIÓN de MOVILIDAD de UTRAN (Caso 1 y Caso 2).

Tras la recepción de la CONFIRMACIÓN/el FALLO de INFORMACIÓN de MOVILIDAD de UTRAN (Caso 1 y Caso 2), finaliza el procedimiento de Reubicación.

Actualización de URA/ Célula y Reubicación de SRNS Combinada (Portadoras de radio sin discontinuidades)

El procedimiento de la presente invención puede iniciarse al decidir realizar el RNC fuente una reubicación de SRNS. Las etapas de este procedimiento, que se han analizado anteriormente y que vuelven a expresarse a continuación, se muestran en mayor detalle en la figura 14. En este caso, el Caso 1 representa la situación en la que el equipo de usuario (UE) no está involucrado y el Caso 2 representa la situación en la que el UE está involucrado y se realiza una Actualización de URA/ Célula y reubicación de SRNS Combinada.

En una etapa inicial, una Instrucción de Reubicación de RANAP se recibe por el RNC fuente a partir de la CN, que indica las RAB que van a liberarse. El RNC fuente continúa la transmisión de datos de enlace descendente sobre las portadoras de radio que soportan una reubicación de SRNS sin discontinuidades hasta que el RNC objetivo se hace el RNC de servicio. El RNC objetivo se hace el RNC de servicio cuando se envía el mensaje de Detección de Reubicación RANAP.

El RNC objetivo envía un mensaje de INFORMACIÓN de MOVILIDAD de UTRAN (Caso 1) en la SRB#1 (UM/ DCCH) o en la SRB#2 (AM/ DCCH), o un mensaje de CONFIRMACIÓN de ACTUALIZACIÓN de URA/ CÉLULA (caso 2) en la SRB#1 (UM/ DCCH), que configura el UE con la U–RNTI nueva.

Si va a usarse la SRB#1, el RNC objetivo establece la entidad de RLC de UM y el valor de HFN de DL se ajusta al valor de HFN de DL actual aumentado en uno. En la entidad de RLC de UM, se usa una “L1 Especial” preferentemente para indicar que una SDU de RLC se inicia en el inicio de una PDU de RLC.

Si va a usarse la SRB#2, el RNC objetivo establece la entidad de RLC de AM y los valores de HFN de DL y de UL se ajustan a los valores de HFN de DL y de UL actuales. Antes de enviar un mensaje de INFORMACIÓN de MOVILIDAD de UTRAN, el lado de transmisión de la entidad de RLC de AM inicia un procedimiento de REAJUSTE de RLC para sincronizar los valores de HFN entre la UTRAN y el UE.

Tras la recepción por el UE del mensaje, la entidad de RLC para la SRB#2 se (r)establece tanto en el lado de UTRAN como en el de UE, y sus valores de HFN se ajustan a un valor aumentado en uno. (En este caso, VALOR puede definirse como o bien el valor actual de HFN o MAX (HFN de UL de la SRB2 | HFN de DL de la SRB2)).

Si el UE se ha configurado con éxito a sí mismo, enviará un mensaje de CONFIRMACIÓN de INFORMACIÓN de MOVILIDAD de UTRAN (Caso 1 y Caso 2). Estos mensajes contienen preferentemente los valores de INICIO (para usarse en protección de integridad y en cifrado sobre las portadoras de radio que usan RLC de UM y de AM).

Tras la recepción y el acuse de recibo por la UTRAN del mensaje, la UTRAN inicializa y el UE reinicializa las entidades de compresión de cabecera de PDCP de las portadoras de radio configuradas para usar un protocolo de compresión de cabecera. Las entidades de RLC para las portadoras de radio afectadas (que no sean la SRB#2) se (r)establecen tanto en el lado de UTRAN como en el de UE. Los valores de HFN para cada RB se ajustan preferentemente al valor de INICIO en el mensaje para el dominio de CN correspondiente y todas las memorias intermedias de datos se ponen a nivel. En caso de fallo, el UE enviará un mensaje de FALLO de INFORMACIÓN de MOVILIDAD de UTRAN (Caso 1 y Caso 2). Tras la recepción del mensaje de CONFIRMACIÓN/FALLO deINFORMACIÓN de MOVILIDAD de UTRAN (Caso 1 y Caso 2), finaliza el procedimiento de Reubicación.

En las realizaciones anteriores, para iniciar el procedimiento la UTRAN puede transmitir un mensaje de5 INFORMACIÓN de MOVILIDAD de UTRAN al UE en el DCCH de enlace descendente usando un RLC de AM o de UM. En el caso de una reubicación de SRNS, el mensaje puede enviarse usando un RLC de UM sólo.

Procedimientos de Actualización de Célula y de URA Procedimientos de Movilidad de Conexión de RRC/Portadoras de radio de señalización

Cuando un mensaje de RRC se transmite en el DL sobre el DCCH o CCCH o SHCCH usando un UM de RLC, el

10 RRC indicará preferentemente al RLC que ha de usarse un indicador de longitud de RLC especial. El UE puede suponer que se ha dado esta indicación. El indicador de longitud especial indica que una SDU de RLC se inicia en el inicio de una PDU de RLC.

La recepción de un mensaje de ACTUALIZACIÓN CÉLULA/ ACTUALIZACIÓN de URA por la UTRAN en base a un indicador de longitud especial de este tipo se analizará a continuación de acuerdo con una realización de la presente15 invención. Cuando la UTRAN recibe un mensaje de ACTUALIZACIÓN CÉLULA/ ACTUALIZACIÓN de URA, la UTRAN:

1> en el caso en el que el procedimiento se activó por la recepción de una ACTUALIZACIÓN de CÉLULA:

2> si se realizó la reubicación de SRNS:

20 3> transmitir un mensaje de CONFIRMACIÓN de ACTUALIZACIÓN de CÉLULA en el DCCH de enlace descendente

2> en otro caso:

25 3> actualizar el valor de INICIO para cada dominio de CN tal como se mantiene en la UTRAN con “INICIO” en la “lista de INICIO” de IE para el dominio de CN tal como se indica por “identidad de dominio de CN” en la “lista de INICIO” de IE; 3> si este procedimiento se activó mientras que el UE no se encontraba en el estado de

30 DCH_DE_CÉLULA, entonces para cada dominio de CN tal como se indica por “identidad de dominio de CN” en la “lista de INICIO” de IE;

4> ajustar los 20 MSB del HFN de MAC–d con el valor de INICIO correspondiente en la “lista de INICIO” de IE; 35 4> ajustar los LSB restantes del HFN de MAC–d a cero.

3> transmitir un mensaje de CONFIRMACIÓN de ACTUALIZACIÓN de CÉLULA en el DCCH de enlace descendente u opcionalmente en el CCCH pero sólo si no se requiere el cifrado; y

40 3> incluir opcionalmente el “indicador de restablecimiento de RLC (RB5 y superiores)” de IE para solicitar un restablecimiento de RLC en el UE, caso en el que las entidades de RLC correspondientes deberían de restablecerse también en la UTRAN; o

1> en el caso de que el procedimiento se activara por la recepción de una ACTUALIZACIÓN de URA: 45 2> si se realizó la reubicación de SRNS:

3> transmitir un mensaje de CONFIRMACIÓN de ACTUALIZACIÓN de URA en el DCCH de enlace descendente 50 2> en otro caso:

3> transmitir un mensaje de CONFIRMACIÓN de ACTUALIZACIÓN de URA en el CCCH

o DCCH de enlace descendente

55 2> incluir la “identidad de URA” de IE en el mensaje de CONFIRMACIÓN de ACTUALIZACIÓN de URA en una célula en la que se radiodifunden múltiples identificadores de URA, o

1> iniciar un procedimiento de liberación de conexión de RRC transmitiendo un mensaje de LIBERACIÓN60 DE CONEXIÓN DE RRC en el CCCH de enlace descendente. En particular, la UTRAN debería:

2> si el mensaje de ACTUALIZACIÓN de CÉLULA se envió debido a un error no recuperable en la RB2, RB3, o RB4:

3> iniciar un procedimiento de liberación de conexión de RRC transmitiendo un mensajede LIBERACIÓN DE CONEXIÓN DE RRC en el CCCH de enlace descendente.

5 Recepción de Mensaje de CONFIRMACIÓN de ACTUALIZACIÓN de CÉLULA/CONFIRMACIÓN de ACTUALIZACIÓN de URA por el UE

Cuando el UE recibe un mensaje de CONFIRMACIÓN de ACTUALIZACIÓN de CÉLULA/ CONFIRMACIÓN de ACTUALIZACIÓN de URA; y

-

si el mensaje se recibe en el CCCH y “URNTI” de IE se encuentra presente y tiene el mismo valor que la 10 variable U_RNTI; o

-

si el mensaje se recibe sobre el DCCH;

el UE puede: 15

-

si el mensaje de CONFIRMACIÓN de ACTUALIZACIÓN de CÉLULA incluye el “indicador de restablecimiento de RLC (RB2, RB3, y RB4)” de IE;

-

restablecer las entidades de RLC para la portadora de radio de señalización RB2, para la portadora de 20 radio de señalización RB3 y para la portadora de radio de señalización RB4 (si se han establecido);

-

si el valor del “Estatus” de IE en la variable ESTATUS_DE_CIFRADO del dominio de CN que se almacenaen la variable ÚLTIMO_DOMINIO_DE_CN_CONFIGURADO se ajusta a “Iniciado”;

25 - ajustar los valores de HFN para las entidades de RLC de AM con identidad de RB 2, identidad de RB 3 e identidad de RB 4 (si se han establecido) igual al valor de INICIO que se incluye en el último mensaje deACTUALIZACIÓN de CÉLULA transmitido para el dominio de CN que se almacena en la variable ÚLTIMO_DOMINIO_DE_CN_CONFIGURADO;

Las realizaciones y ventajas anteriores son meramente a modo de ejemplo y no ha de interpretarse que limitan la

30 presente invención. Las presentes enseñanzas pueden aplicarse fácilmente a otros tipos de aparatos. Se pretende que la descripción de la presente invención sea ilustrativa, y que no limite el alcance de las reivindicaciones. Muchas alternativas, modificaciones y variaciones serán evidentes para los expertos en la técnica. En las reivindicaciones, se pretende que las cláusulas de medios más funciones cubran las estructuras que se describen en el presente documento tal como que realizan la función referida y no sólo unas equivalentes estructurales sino también

35 estructuras equivalentes.

Claims (6)

1. REIVINDICACIONES

   1. Un procedimiento para realizar una reubicación de Subsistema de Red Radio de Servicio, SRNS, que comprende:

   -

   recibir en una información de recursos de radio de Controlador de Red Radio, RNC, objetivo a partir de un

   RNC fuente, incluyendo dicha información de recursos de radio unos parámetros de cifrado, uno de los 5 cuales es un Número de Hipertrama, HFN;

   -

   cifrar una unidad de datos en el RNC objetivo con los parámetros de cifrado recibidos; y

   -

   transmitir la unidad de datos cifrada desde el RNC objetivo hasta un terminal de usuario, UE,

   caracterizado porque uno de dichos parámetros de cifrado es una variable de estado, VT(US), que indica un valor de número de secuencia que sigue de forma consecutiva el número de secuencia de una unidad de datos que se 10 transmitió por última vez desde el RNC fuente hasta el terminal de usuario.

2. 2.

   El procedimiento de la reivindicación 1, en el que el RNC objetivo y el terminal de usuario están funcionando en el modo UM.

3. 3.

   El procedimiento de la reivindicación 1, que además comprende: transmitir la unidad de datos por un canal DCCH de UM.

   15 4. El procedimiento de la reivindicación 1, que además comprende: transmitir la unidad de datos por una portadora de radio de servicio SRB1.
4. 5. El procedimiento de la reivindicación 1, en el que la etapa de transmisión incluye transmitir un indicador de inicio de datos con la unidad de datos.
5. 6. El procedimiento de la reivindicación 7, en el que dicho indicador de inicio de datos indica que la unidad de datos 20 no se incluye como parte de una SDU que se transmitió previamente al terminal de usuario.
6. 7. Controlador de Red Radio, RNC, que tiene un receptor, una unidad de cifrado y un transmisor y que está adaptado para realizar una reubicación de Subsistema de Red Radio de Servicio, SRNS de acuerdo con el procedimiento de una cualquiera de las reivindicaciones anteriores.