ES2578260T3 - Procedimiento de reubicación de SRNS en un sistema de comunicación móvil - Google Patents

Procedimiento de reubicación de SRNS en un sistema de comunicación móvil Download PDF

Info

Publication number
ES2578260T3
ES2578260T3 ES07021120.6T ES07021120T ES2578260T3 ES 2578260 T3 ES2578260 T3 ES 2578260T3 ES 07021120 T ES07021120 T ES 07021120T ES 2578260 T3 ES2578260 T3 ES 2578260T3
Authority
ES
Spain
Prior art keywords
radio
rlc
terminal
message
relocation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
ES07021120.6T
Other languages
English (en)
Inventor
Seung-June Yi
Woon-Young Yeo
So-Young Lee
Hyo-Sang Han
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LG Electronics Inc
Original Assignee
LG Electronics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by LG Electronics Inc filed Critical LG Electronics Inc
Application granted granted Critical
Publication of ES2578260T3 publication Critical patent/ES2578260T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0457—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply dynamic encryption, e.g. stream encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/24—Radio transmission systems, i.e. using radiation field for communication between two or more posts
    • H04B7/26—Radio transmission systems, i.e. using radiation field for communication between two or more posts at least one of which is mobile
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H04W12/037—Protecting confidentiality, e.g. by encryption of the control plane, e.g. signalling traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/06—Registration at serving network Location Register, VLR or user mobility server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1809—Selective-repeat protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/1874—Buffer management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/12—Reselecting a serving backbone network switching or routing node
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02—Data link layer protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Radio Relay Systems (AREA)
  • Crystals, And After-Treatments Of Crystals (AREA)
  • Metal-Oxide And Bipolar Metal-Oxide Semiconductor Integrated Circuits (AREA)
  • Radio Transmission System (AREA)

Abstract

Un procedimiento de reubicación de un controlador de red de radio servidor, que comprende: recibir, mediante un controlador de red de radio objetivo, una pluralidad de valores de parámetros de cifrado desde un controlador de red de radio de origen, en el que la pluralidad de valores de parámetros de cifrado son para una primera portadora de radio o una segunda portadora de radio, en el que al menos uno de la pluralidad de valores de parámetros de cifrado es un número de híper trama, y en el que uno de la pluralidad de valores de parámetros de cifrado es una variable de estado, en lo sucesivo denominado como VT(US), que indica un valor de número de secuencia que sigue consecutivamente un número de secuencia de una última unidad de datos transmitida desde el controlador de red de radio de origen a un terminal; y si la segunda portadora de radio se ha de usar, determinar un valor mayor entre un número de híper trama de enlace descendente y un número de híper trama de enlace ascendente de la segunda portadora de radio; incrementar el valor mayor determinado en uno; y usar el número de híper trama incrementado como el número de trama de enlace ascendente y de enlace descendente.

Description

5
10
15
20
25
30
35
40
45
50
55
DESCRIPCION
Procedimiento de reubicacion de SRNS en un sistema de comunicacion movil Antecedentes de la invencion
1. Campo de la invencion
Esta invencion se refiere en general a sistemas de comunicacion inalambrica, y mas particularmente a un sistema y procedimiento para realizar un procedimiento de reubicacion de sub-sistema de red de radio servidor (SRNS) en un sistema de comunicacion.
2. Antecedentes de la tecnica relacionada
Un sistema universal de telecomunicaciones moviles (UMTS) es un sistema de comunicacion movil de la tercera generacion que ha evolucionado desde una norma conocida como el Sistema Global para Comunicaciones Moviles (GSM). Esta norma es una norma europea que tiene por objeto proporcionar un servicio de comunicacion movil mejorado basandose en una red principal de GSM y en la tecnologfa de acceso multiple por division de codigo de banda ancha (W-CDMA). En diciembre de 1998, el ETSI de Europa, el ARIB/TTC de Japon, el T1 de los Estados Unidos, y el TTA de Corea formaron un Proyecto Comun de Tecnologfas Inalambricas de la Tercera Generacion (3GPP) para el fin de crear una especificacion para normalizar el UMTS.
El trabajo hacia la normalizacion del UMTS realizado por el 3GPP ha dado como resultado la formacion de cinco grupos de especificacion tecnica (TSG), cada uno de los cuales esta dirigido a formar elementos de red que tienen operaciones independientes. Mas espedficamente, cada TSG desarrolla, aprueba y gestiona una especificacion de la norma en una region relacionada. Entre ellos, un grupo (TSG-RAN) de la red de acceso de radio (RAN) desarrolla una especificacion para la funcion, elementos deseados, e interfaz de una red de acceso de radio terrestre de UMTS (UTRAN), que es una nueva RAN para soportar una tecnologfa de acceso de W-CDMA en el UMTS.
El grupo TSG-RAN incluye un grupo plenario y cuatro grupos de trabajo. El grupo de trabajo 1 (WG1) desarrolla una especificacion para una capa ffsica (una primera capa). El grupo de trabajo 2 (WG2) especifica las funciones de una capa de enlace de datos (una segunda capa) y de una capa de red (una tercera capa). El grupo de trabajo 3 (WG3) define una especificacion para una interfaz entre una estacion base en la UTRAN, un controlador de red de radio (RNC), y una red principal. Finalmente, el grupo de trabajo 4 (WG4) analiza terminos deseados para un rendimiento de enlace de radio y elementos deseados para gestion de recursos de radio.
La Figura 1 muestra una estructura de una UTRAN de 3GPP a la que puede aplicarse la presente invencion. Esta UTRAN incluye uno o mas sub-sistemas de red de radio (RNS). Cada RNS incluye un RNC y uno o mas Nodos B (por ejemplo, una estacion base) gestionados por los RNC. Los RNC estan conectados a un centro de conmutacion movil (MSC) que realiza comunicaciones de intercambio de lmea con la red de GSM. Los RNC estan tambien conectados a un nodo de soporte de servicio general de paquetes de radio servidor (SGSN) que realiza comunicaciones de intercambio de paquetes con una red de servicio general de paquetes de radio (GPRS).
Los Nodos B estan gestionados por los RNC, reciben informacion enviada mediante la capa ffsica de un terminal (por ejemplo, estacion movil, equipo de usuario y/o unidad de abonado) a traves de un enlace ascendente, y transmiten datos a un terminal a traves de un enlace descendente. Los Nodos B, por lo tanto, operan como puntos de acceso de la UTRAN para el terminal.
Los RNC realizan funciones que incluyen asignar y gestionar recursos de radio. Un RNC que gestiona directamente un Nodo B se denomina como un RNC de control (CRNC). El CRNC gestiona recursos de radio comunes. Un RNC servidor (SRNC), por otra parte, gestiona recursos de radio especializados asignados a los respectivos terminales. El CRNC puede ser el mismo que el SRNC. Sin embargo, cuando el terminal se desvfa de la region del SRNC y se mueve a la region de otro RNC, el CRNC puede ser diferente del SRNC. Puesto que las posiciones ffsicas de diversos elementos en la red de UMTS pueden variar, es necesaria una interfaz para conectar los elementos. Los Nodos B y los RNC estan conectados entre sf mediante una interfaz lub. Estan conectados dos RNC entre sf mediante una interfaz lur. Una interfaz entre el RNC y una red principal se denomina como lu.
Los servicios proporcionados al UE pueden clasificarse en general en servicios de conmutacion de circuitos y servicios de conmutacion de paquetes. Puede incluirse un servicio de telefoma de voz en el servicio de conmutacion de circuitos y puede incluirse un servicio de exploracion web en un servicio de conmutacion de paquetes a traves de una conexion a internet. El servicio de conmutacion de circuitos esta conectado a un MSC de la red principal, y este MSC esta conectado a un centro de conmutacion movil de pasarela (GMSC) para comunicar con una o mas redes externas. El GMSC gestiona las conexiones entre el MSC y las redes externas.
El servicio de conmutacion de paquetes esta conectado a un nodo de soporte (SGSN) del servicio general de paquetes de radio (GPRS), este nodo esta conectado a un nodo de soporte (GgSN) de GPRS de pasarela de la red principal. El SGSN comunica paquetes entre el SRNC y el GGSN, y el GGSN gestiona conexiones entre el SGSN y otra red de conmutacion de paquetes tal como internet.
5
10
15
20
25
30
35
40
45
50
55
Se proporciona una diversidad de interfaces para realizar intercambios de datos mutuos entre estos componentes de red. Una interfaz entre un RNC y la red principal se conoce como una interfaz lu. Cuando la lu esta conectada al dominio de conmutacion de paquetes, se denomina una interfaz lu PS, y cuando la lu esta conectada al dominio de conmutacion de circuitos se denomina una interfaz lu CS.
La Figura 2 muestra una estructura de un protocolo de interfaz de acceso de radio entre un terminal que opera basandose en una especificacion de RAN de 3GPP y una UTRAN. El protocolo de interfaz de acceso de radio esta formado horizontalmente de una capa ffsica (PHY), una capa de enlace de datos, y una capa de red y esta divido verticalmente en un plano de control para transmitir informacion de control y un plano de usuario para transmitir informacion de datos. El plano de usuario es una region a la que se transmite informacion de trafico de un usuario tal como voz o un paquete de IP. El plano de control es una region a la que se transmite informacion de trafico control tal como una interfaz de una red o mantenimiento y gestion 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) basandose en tres capas inferiores de un modelo de la norma de interconexion de sistemas abiertos (OSI) bien conocido en un sistema de comunicacion. La primera capa (L1) opera como una capa ffsica (PHY) para una interfaz de radio y esta conectada a una capa de control de acceso al medio (MAC) superior a traves de uno o mas canales de transporte. La capa ffsica transmite datos entregados a la capa ffsica (PHY) a traves de un canal de transporte a un receptor usando diversos procedimientos de codificacion y modulacion adecuados para las circunstancias de radio. El canal de transporte entre la capa ffsica (PHY) y la capa de MAC se divide en un canal de transporte especializado y un canal de transporte comun basandose en si se usa exclusivamente por un unico terminal o se comparte por varios terminales.
La segunda capa L2 opera como una capa de enlace de datos y permite a diversos terminales compartir 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 del protocolo de convergencia de datos en paquetes (PDCP), y una capa de control de difusion/multidifusion (BMC).
La capa de MAC entrega datos a traves de una relacion de mapeo apropiada entre un canal logico y un canal de transporte. Los canales logicos conectan una capa superior a la capa de MAC. Se proporcionan diversos canales logicos basandose en el tipo de informacion transmitida. En general, cuando se transmite informacion del plano de control, se usa un canal de control. Cuando se transmite la informacion del plano de usuario, se usa un canal de trafico. La capa de MAC se divide en dos sub-capas de acuerdo con las funciones realizadas. Las dos sub-capas son una sub-capa de MAC-d que se situa en el SRNC y gestiona el canal de transporte especializado y una sub- capa de MAC-c/sh que se situa en el CRNC y gestiona el canal de transporte comun.
La capa de RLC forma una unidad de datos de protocolo (PDU) de RLC apropiada adecuada para la transmision mediante las funciones de segmentacion y concatenacion de una unidad de datos de servicio (SDU) de RLC recibida desde una capa superior. La capa de RLC tambien realiza una funcion de solicitud de repeticion automatica (ARQ) mediante la cual se re-transmite una PDU de RLC perdida durante la transmision. La capa de RLC opera en tres modos: un modo transparente (TM), un modo sin acuse de recibo (UM), y un modo con acuse de recibo (AM). El modo seleccionado depende del procedimiento usado para procesar la SDU de RLC recibida desde la capa superior. Una memoria intermedia de RLG almacena las SDU de RLC o las PDU de RLC recibidas desde la capa superior. Seguira una explicacion mas detallada de los modos de operacion de la capa de RLC.
La capa del protocolo de convergencia de datos en paquetes (PDCP) es una capa superior de la capa de RLC que permite que se transmitan elementos de datos a traves de un protocolo de red tal como IP.v4 o IP.v6. Puede usarse una tecnica de compresion de encabezamientos para comprimir y transmitir la informacion de encabezamiento en un paquete para la transmision eficaz del paquete de IP.
La capa de control de difusion/multidifusion (BMC) permite que se transmita un mensaje desde un centro de diffusion de celula (CBC) a traves de la interfaz de radio. La funcion principal de la capa de BMC es planificar y transmitir un mensaje de diffusion de celula a un terminal. En general, los datos se transmiten a traves de la capa de RLC que opera en el modo sin acuse de recibo.
La capa de PDCP y la capa de BMC estan conectadas al SGSN puesto que se usa un procedimiento de intercambio de paquetes, y estan ubicadas unicamente en el plano de usuario puesto que transmiten unicamente datos de usuario. A diferencia de la capa de PDCP y de la capa de BMC, la capa de RLC puede incluirse en el plano de usuario y en el plano de control de acuerdo con una capa conectada a la capa superior. Cuando la capa de RLC pertenece al plano de control, se reciben los datos desde una capa de control de recursos de radio (RRC).
En general, el servicio de transmision de datos de usuario proporcionado a la capa superior mediante la segunda capa (L2) en el plano de usuario se denomina como una portadora de radio (RB). El servicio de transmision de informacion de control proporcionado a la capa superior mediante la segunda capa (L2) en el plano de control se denomina como una portadora de radio de senalizacion (SRB). Como se muestra en la Figura 2, puede existir una pluralidad de entidades en las capas de RLC y de PDCP. Esto es debido a que el terminal tiene una pluralidad de RB, y una o dos entidades de RLC y se usa generalmente unicamente una entidad de PDCP para una RB. Las
5
10
15
20
25
30
35
40
45
50
55
entidades de la capa de RLC y de la capa de PDCP pueden realizar una funcion independiente en cada capa.
La capa de RRC situada en la porcion mas baja de la tercera capa (L3) se define unicamente en el plano de control y controla los canales logicos, los canales de transporte y los canales ffsicos en relacion con el ajuste, el re-ajuste, y la cancelacion de las RB. En este momento, configurar la RB significa procedimientos para estipular las caractensticas de una capa de protocolo y un canal, que se requieren para proporcionar un servicio espedfico, y ajustar los parametros detallados respectivos y procedimientos de operacion. Es posible transmitir mensajes de control recibidos desde la capa superior a traves de un mensaje de RRC.
La operacion de la portadora de radio y de la capa de RLC se describira ahora en detalle. Como se ha analizado anteriormente, una portadora de radio (RB) es un servicio de transmision que entrega datos de usuario en el plano de usuario a una capa superior a traves de la segunda capa L2. El servicio de transmision que entrega informacion de control en el plano de control a la capa superior a traves de la segunda capa L2 se define como una portadora de radio de senalizacion (SRB).
Como se ha indicado anteriormente, la capa de RLC opera en uno de tres modos: modo transparente (TM), modo sin acuse de recibo (UM), y modo con acuse de recibo (AM).
Cuando opera en el modo de TM, la informacion de encabezamiento no se anade a la SDU de RLC recibida desde la capa superior, no se adjunta ningun numero de secuencia a la PDU de RLC y no se realiza la re-transmision de datos. Tambien, aunque en general no se realiza la segmentacion y reensamblaje de la SDU de RLC, el uso de segmentacion y reensamblaje cuando se configura la portadora de radio se determina en ciertas circunstancias.
Cuando opera en modo de UM, no se realiza la re-transmision de PDU de RLC incluso cuando tiene lugar un fallo de transmision. El receptor no solicita la re-transmision de datos. En su lugar, se toma un enfoque diferente. En modo de UM, la capa de RLC construye las PDU de RLC segmentando o concatenando las SDU de RLC, y a continuacion adjuntando numeros de secuencia a las PDU de RLC. El receptor puede restaurar datos perdidos basandose en los numeros de secuencia mediante un procedimiento de re-ensamblaje.
Cuando opera en el modo de AM, se usa la re-transmision para soportar transmision libre de errores de la siguiente manera. Se transmite informacion de estado que corresponde a la PDU de RLC recibidas desde el receptor en forma de un Informe de Estado. Despues de recibir este informe, el transmisor re-transmite las PDU de RLC transmitidas insatisfactoriamente.
Mas espedficamente, en modo de AM, el transmisor forma cada PDU de RLC desde una o mas SDU de RLC que se han recibido desde una capa superior, y la informacion de encabezamiento, (por ejemplo numero de secuencia e indicadores de longitud) se adjunta a continuacion. Puesto que el tamano de una PDU de RLC de AM es fijo, el transmisor segmenta o concatena una o mas SDU de RLC para adaptar el tamano de la PDU. A continuacion, la PDU de RLC formada se almacena en la memoria intermedia de transmision. Las PDU de RLC almacenadas se entregan secuencialmente a la capa de MAC a una velocidad controlada mediante la capa de MAC. Puesto que cada PDU de RLC tiene su propio numero de secuencia, el receptor puede comprobar cuales PDU de RLC se recibieron satisfactoriamente y cuales no. El receptor solicita la re-transmision para las PDU de RLC recibidas insatisfactoriamente al transmisor mediante el Informe de Estado.
El procedimiento de retransmision de AM puede entenderse mas evidentemente mediante el siguiente ejemplo. Si los numeros de secuencia de las PDU de RLC recibidas son N.° 23, N.° 24, N.° 25, N.° 32, y N.° 34, el receptor considera que las PDU de RLC que tiene los numeros de secuencia de N.° 26 a N.° 31 y N.° 33 se pierden durante la transmision. El receptor a continuacion envfa un Informe de Estado al transmisor, y el transmisor comprueba el Informe de Estado, y retransmite las PDU de RLC transmitidas insatisfactoriamente, es decir N.° 26 a N.° 31 y N.° 33.
La Figura 3 muestra la estructura de una PDU de RLC de modo de AM o de UM usada en la capa de RLC. La PDU de RLC esta comprendida de un encabezamiento y una cabida util. El encabezamiento mostrado incluye un numero de secuencia y un indicador de longitud. El numero de secuencia se usa como un identificador de la correspondiente PDU de RLC, y el indicador de longitud indica un lfmite de la SDU de RLC. Los numeros de secuencia pueden ser, por ejemplo, 7 (siete) bits para modo de UM, y 12 (doce) bits para modo de AM. Puede incluirse un campo de 1 (uno) bit E para indicar si el siguiente campo es el indicador de longitud o datos.
El indicador de longitud se usa para indicar el lfmite de cada SDU de RLC que finaliza en la PDU de RLC. Por lo tanto, el indicador de longitud puede no estar presente si la SDU de RLC no se finaliza en la PDU de RLC. El indicador de longitud puede usarse tambien 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 SDU de RLC a concatenar. El relleno puede tener cualquier valor y el receptor y el emisor no lo tienen en cuenta. Cuando se usa como un indicador de inicio de datos el indicador de longitud puede indicar que la SDU de RLC empieza en el comienzo de la PDU de RLC.
El indicador de inicio de datos es util puesto que puede evitar perdida de datos adicional en el RLC de UM. Por ejemplo, suponiendo que se pierde una PDU de RLC de numero de secuencia N.° 4 y se recibe una PDU de RLC de
5
10
15
20
25
30
35
40
45
50
numero de secuencia N.° 5. Suponiendo ademas que una nueva SDU de RLC empieza en el comienzo de la PDU de numero de secuencia N.° 5 y finaliza en la PDU de numero de secuencia N.° 5. En este caso, puesto que la SDU de RLC empieza en el comienzo de la PDU de numero de secuencia N.° 5, el indicador de inicio de datos esta presente en el encabezamiento de la PDU de numero de secuencia N.° 5. Pero, si el indicador de inicio de datos no esta presente, la capa de RLC del receptor considera que unicamente se reciben los segmentos continuados de una SDU de RLC contenidos en la PDU de RLC de numero de secuencia N.° 5. En este caso, el receptor descarta los segmentos puesto que el receptor piensa que no se ha recibido la SDU de RLC completa.
La Figura 4 muestra una instantanea ejemplar del estado de una memoria intermedia de un RLC. Como se muestra, las PDU de RLC se almacenan secuencialmente en la memoria intermedia y las PDU de RLC transmitidas satisfactoriamente se borran de la memoria intermedia. Como se muestra, la capa de RLC usa variables de estado para gestionar la transmision de datos usando la memoria intermedia de RLC.
Cuando se opera en modo de AM, la capa de RLC usa una variable de estado VT(S) para indicar el numero de secuencia de la siguiente PDU de RLC a transmitir por primera vez, y una variable de estado VT(A) para indicar el numero de secuencia de la primera PDU de RLC a realizar acuse de recibo de manera positiva mediante el receptor. El estado de la memoria intermedia indica por lo tanto que el transmisor ha transmitido las PDU de RLC hasta la PDU de numero de secuencia de VT(S)-1 y ha recibido acuses de recibo positivos hasta la PDU de RLC de VT(A)-1 desde el receptor.
Cuando se opera en el modo de UM, la capa de RLC usa una variable de estado VT(US) que es similar a VT(S) en modo de AM. Es decir, VT(US) indica el numero de secuencia de la siguiente PDU de RLC a transmitir. Sin embargo, puesto que no hay realimentacion desde el receptor en modo de UM, la variable de estado tal como VT(A) no esta definida.
En ambos modos de operacion, el valor inicial de las variables de estado puede establecerse a 0 (cero). Cuando se establece, re-establece o resetea la capa de RLC, las variables de estado se establecen a este valor inicial.
Volviendo ahora al protocolo de comunicaciones de radio mostrado en la Figura 2, como se ha indicado anteriormente, el servicio proporcionado a la capa superior mediante la segunda capa L2 en el plano de control se define como una portadora de radio de senalizacion (SRB). En operacion, todos los mensajes de RRC se intercambian entre el terminal y el RNC a traves de las portadoras de radio de senalizacion SRB. Usando los mensajes de RRC, el RNC puede configurar, modificar y liberar las portadoras de radio segun sea necesario para, por ejemplo, realizar un procedimiento de reubicacion de SRNS, los detalles del cual se describen en mayor detalle a continuacion.
Las caractensticas de la portadora de radio de senalizacion (SRB) como se ha indicado anteriormente se determinan basandose en el modo de operacion del RLC y el tipo de canal logico usado. Un canal de control comun (CCCH) y canal de control especializado (DCCH) se usan para las SRB. El CCCH es un canal logico que lleva informacion de control comun a varios terminales. Puesto que el CCCH es un canal logico comun, el CCCH contiene una identidad temporal de red de radio de UTRAN (U-RNTI) para identificar a un terminal espedfico. El DCCH es un canal logico que lleva informacion de control especializada para un terminal espedfico.
Las caractensticas de cada tipo de SRB son las siguientes.
SRB0: para el enlace ascendente (UL) se usa RLC de TM, y para el enlace descendente (DL) se usa RLC de UM. El canal logico usado para la SRB0 es CCCH.
SRB1: se usa RLC de UM, y el canal logico es DCCH.
SRB2: se usa RLC de AM, y el canal logico es DCCH. La SRB2 lleva unicamente los mensajes generados en la capa de RRC. La SRB2 no lleva los mensajes de capa superior.
SRB3: se usa RLC de AM, y el canal logico es DCCH. La SRB3 lleva los mensajes recibidos desde la capa superior.
SRB4: se usa RLC de AM, y el canal logico es DCCH. La SRB4 tambien lleva los mensajes recibidos desde la capa superior. La diferencia es que la SRB3 lleva mensajes de prioridad superior mientras que la SRB4 lleva mensajes de prioridad inferior.
SRB5-31: se usa RLC de TM, y el canal logico es DCCH. Estas SRB se usan opcionalmente.
Procedimiento de reubicacion de SRNS
La Figura 5 es un diagrama que muestra como puede realizarse un procedimiento de sub-sistema de red de radio servidor (SRNS) en un dominio de servicio basado en conmutacion de paquetes. Como se muestra, este procedimiento implica cambiar el RNS que sirve a un terminal de usuario desde un RNS (o RNC) a otro. Cuando se hace este cambio, se prefiere establecer la ruta mas corta entre el terminal y la red principal cambiando el punto de conexion lu. Como se muestra adicionalmente, cambiar el punto de conexion lu puede producir en algunos casos que la red principal cambie desde un SGSN (antiguo SGSN) a otro (nuevo SGSN) para fines de realizar
5
10
15
20
25
30
35
40
45
50
comunicaciones con el terminal de usuario. El procedimiento de reubicacion de SRNS puede realizarse tambien en el dominio de servicio basado en conmutacion de circuitos.
Un procedimiento de reubicacion de SRNS puede realizarse por al menos las siguientes razones:
• Cambio de punto de conexion: se realiza reubicacion para mover la UTRAN a un punto de conexion de CN en el lado de la UTRAN desde el RNC de origen al RNC objetivo.
• Traspaso definitivo combinado: se realiza la reubicacion para mover la UTRAN a un punto de conexion de CN en el lado de la UTRAN desde el RNC de origen al RNC objetivo, mientras se realiza un traspaso definitivo decidido por la UTRAN.
• Actualizacion de celula/URA combinada: se realiza la reubicacion para mover la UTRAN al punto de conexion de CN en el lado de la UTRAN desde el RNC de origen al RNC objetivo, mientras se realiza una re-seleccion de celula en la UTRAN.
Como se analizara en mayor detalle, un procedimiento de reubicacion de SRNS puede requerir el uso de diferentes portadoras de radio dependiendo del modo de operacion de la capa de RLC.
La reubicacion de SRNS se clasifica normalmente en dos casos: (1) caso de terminal no implicado (Caso I) y (2) caso de terminal implicado (Caso II). En el Caso I, la reubicacion de SRNS se inicia mediante una decision propia de la red y el terminal no conoce si la reubicacion de SRNS se realiza hasta que se termina el procedimiento de reubicacion. En el Caso II, la reubicacion de SRNS se inicia como resultado de la solicitud de cambio de celula del terminal (por ejemplo, traspaso) y el terminal conoce la reubicacion de SRNS en el comienzo del procedimiento. Aunque los casos I y II son diferentes en que uno esta implicado con el terminal y el otro no, los dos casos no tienen diferencia sustancial con respecto al procedimiento de reubicacion de SRNS. Una explicacion mas detallada de este procedimiento sigue ahora.
Durante el procedimiento de reubicacion de SRNS, se intercambian diversos mensajes de senalizacion entre el terminal y un RNC, entre el RNC y otro RNC, y entre uno de los RNC y la red principal.
La Figura 6 muestra el intercambio de mensajes de senalizacion que tiene lugar entre el terminal y la red principal en el procedimiento de reubicacion de SRNS del UMTS. En este intercambio, el “RNC de origen” es el RNC que desempena el papel del SRNC antes de la reubicacion de SRNS y el “RNC objetivo” es el RNC que desempena el papel del SRNC despues de la reubicacion de SRNS. De manera similar, el “antiguo SGSN” es el SGSN antes del procedimiento de reubicacion y el “nuevo SGSN” es el SGSN despues del procedimiento de reubicacion. Aunque se muestra que el antiguo y el nuevo SGSN son diferentes, el antiguo SGS-N y el nuevo SGSN pueden ser el mismo en ciertas circunstancias. Ademas, el procedimiento mostrado en la Figura 6 puede aplicarse a tanto el Caso I como el Caso II.
Las etapas del procedimiento de reubicacion de SRNS se resumiran ahora. En una etapa inicial, etapa 1, el RNC de origen decide realizar una reubicacion de SRNS. Puede usarse cualquiera del Caso I o el Caso II para activar el procedimiento de reubicacion.
En la etapa 2, el RNC de origen envfa un mensaje de Reubicacion Requerida al antiguo SGSN. El mensaje Reubicacion Requerida incluye informacion para realizar, por ejemplo, co-ordinacion de reubicacion, funcionalidad de seguridad, informacion de contexto de protocolo de RRC y las capacidades del terminal.
En la etapa 3, el antiguo SGSN determina a partir del mensaje de Reubicacion Requerida si la reubicacion de SRNS es reubicacion de SRNS intra-SGSN o inter-SGSN. Se realiza un procedimiento de intra-SGSN cuando el antiguo y el nuevo SGSN son el mismo, y se realiza un procedimiento de inter-SGSN cuando los dos son diferentes. Un mensaje Solicitud de Reubicacion de Reenvfo es aplicable unicamente en el caso de reubicacion de SRNS inter- SGSN.
En la etapa 4, el nuevo SGSN envfa un mensaje de Solicitud de Reubicacion al RNC objetivo de modo que se asignan los recursos necesarios entre el RNC objetivo y el nuevo SGSN. Despues de que todos los recursos necesarios se han asignado satisfactoriamente, el RNC objetivo envfa el mensaje de Acuse de Recibo de Solicitud de Reubicacion al nuevo SGSN.
En la etapa 5, cuando se ha asignado un recurso para la transmision de datos de usuario entre el RNC objetivo y el nuevo SGSN y el nuevo SGSN esta listo para la reubicacion de SRNS, se envfa el mensaje Respuesta de Reubicacion de Reenvfo desde el nuevo SGSN al antiguo SGSN.
En la etapa 6, el antiguo SGSN continua la reubicacion de SRNS enviando un mensaje de Comando de Reubicacion al RNC de origen. El RNC de origen esta listo para reenviar datos de usuario de enlace descendente directamente al RNC objetivo.
En la etapa 7, cuando el RNC de origen esta listo para reenvfo de datos, activa la ejecucion de la reubicacion de SRNS enviando un mensaje de Compromiso de Reubicacion al RNC objetivo.
5
10
15
20
25
30
35
40
45
50
55
En la etapa 8, el RNC de origen empieza a reenviar datos para las portadoras de acceso de radio. El reenvfo de datos puede llevarse a cabo a traves de la interfaz lu, que significa que los datos no se intercambian directamente entre el RNC de origen y el RNC objetivo sino a traves de la red principal.
En la etapa 9, el RNC objetivo envfa un mensaje de Deteccion de Reubicacion al nuevo SGSN. Cuando se envfa el mensaje de Deteccion de Reubicacion, el RNC objetivo inicia la operacion de SRNC.
En la etapa 10, el RNC objetivo envfa un mensaje (Caso I) de informacion de movilidad de UTRAN o un mensaje (Caso II) de actualizacion de Celula/URA (area de registro de UTRAN) al terminal. Ambos mensajes contienen elementos de informacion de terminal y elementos de informacion de red principal. Los elementos de informacion de terminal incluyen la nueva U-RNTI usada para la identificacion del terminal en el RNC objetivo. Los elementos de informacion de red principal incluyen identificacion de area de ubicacion e informacion de identificacion de area de encaminamiento.
Tras la recepcion del mensaje de Informacion de Movilidad de UTRAN el terminal puede empezar a enviar datos de usuario de enlace ascendente (UL) al RNC objetivo. Cuando el terminal se ha reconfigurado a sf mismo, envfa el mensaje de Confirmacion de Informacion de Movilidad de UTRAN al RNC objetivo. Esto indica que el terminal esta listo tambien para recibir datos de enlace descendente (DL) desde el RNC objetivo.
En la etapa 11, tras la recepcion del mensaje de Deteccion de Reubicacion la red principal cambia el plano de usuario desde el RNC de origen al RNC objetivo. En el caso de una reubicacion de SRNS inter-SGSN, el nuevo SGSN envfa mensajes de Solicitud de Contexto de PDP de Actualizacion a los GGSN referidos. Los GGSN actualizan sus campos de contexto de PDP y devuelven una Respuesta de Contexto de PDP de Actualizacion.
En la etapa 12, cuando el RNC objetivo recibe el mensaje de Confirmacion de Informacion de Movilidad de UTRAN, (es decir, la nueva U-RNTI se intercambia satisfactoriamente con el terminal mediante los protocolos de radio), el RNC objetivo envfa el mensaje de Reubicacion Completa al nuevo SGSN. El fin del mensaje de Reubicacion Completa es para indicar mediante el RNC objetivo la finalizacion de la reubicacion del SRNS a la red principal. En el caso de una reubicacion de SRNS inter-SGSN, el nuevo SGSN senaliza al antiguo SGSN de la finalizacion del procedimiento de reubicacion de SRNS enviando un mensaje de Reubicacion de Reenvfo Completa.
En la etapa 13, tras recibir el mensaje de Reubicacion Completa o el mensaje de Reubicacion de Reenvfo Completa, el antiguo SGSN envfa un mensaje de Comando de Liberacion de lu al RNC de origen de modo que se libera la conexion Iu entre el RNC de origen y el antiguo SGSN.
La Figura 7 muestra las etapas del procedimiento de reubicacion 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 ser cualquiera del RNC de origen o RNC objetivo dependiendo del caso. Tambien, el UE se refiere al equipo de usuario y por lo tanto puede incluir un terminal de usuario. Los mensajes de RRC transmitidos en este procedimiento se describen como sigue.
(1) mensaje de actualizacion de celula y mensaje de confirmacion de actualizacion de celula: cuando el terminal se mueve a una nueva celula, se envfa un mensaje de Actualizacion de Celula desde el terminal a la UTRAN. Si la UTRAN decide realizar la reubicacion de SRNS, el RNC objetivo envfa el mensaje de Confirmacion de Actualizacion de Celula al terminal como una respuesta al mensaje de Actualizacion de Celula. El mensaje de Confirmacion de Actualizacion de Celula contiene la nueva U-RNTI, que indica al terminal que se esta realizando el procedimiento de reubicacion de SRNS. El mensaje de Actualizacion de Celula se transmite a traves de SRB0 usando RLC de TM, y el mensaje de Confirmacion de Actualizacion de Celula a traves de cualquiera de SRB0 o SRB1 usando RLC de UM.
(2) mensaje de Actualizacion URA y mensaje de Confirmacion de Actualizacion de URA: una URA (area de registro de UTRAN) es un area comprendida de una o varias celulas, y es conocida internamente para la UTRAN. Las URA pueden solapar parcialmente para evitar un efecto ping-pong del terminal. Por lo tanto, una celula puede pertenecer a una o mas URA. El terminal conoce la identidad de URA actual desde la lista de URA difundida en cada celula y realiza el procedimiento de actualizacion de URA cada vez que la URA se cambia.
El procedimiento de actualizacion de URA se inicia cuando el terminal envfa el mensaje de Actualizacion de URA a la UTRAN. La UTRAN transmite el mensaje de Confirmacion de Actualizacion de uRa en respuesta al mensaje de Actualizacion de URA al terminal, para informar al terminal de la nueva identidad de URA. El mensaje de Confirmacion de Actualizacion de URA incluye una nueva U-RNTI que es la misma que en el mensaje de Confirmacion de Actualizacion de Celula. El mensaje de Actualizacion de URA se transmite a traves de SRB0 usando RLC de TM, y el mensaje de Confirmacion de Actualizacion de URA se transmite a traves de SRB0 o SRB1 usando RLC de UM.
(3) mensaje de Informacion de Movilidad de UTRAN y mensaje de Confirmacion de Informacion de Movilidad de UTRAN: El mensaje de Informacion de Movilidad de UTRAN se usa cuando la UTRAN asigna una nueva U-RNTI al terminal o cuando se transmite informacion de movilidad. El terminal transmite el mensaje de Confirmacion de Informacion de Movilidad de UTRAN en respuesta. Despues de transmitir satisfactoriamente el mensaje de Confirmacion de Informacion de Movilidad de UTRAN, el RNC objetivo y el terminal establecen/re-establece las entidades de PDCP y RLC usando los comandos CPDCP-CONFIG-Req y CRLC-CONFIG-Req, respectivamente.
5
10
15
20
25
30
35
40
45
50
55
El mensaje de Informacion de Movilidad de UTRAN se transmite a traves de SRB1 usando RLC de UM o SRB2 usando RLC de AM. El mensaje de Confirmacion de Informacion de movilidad de UTRAN se transmite a traves de SRB2 usando RLC de AM.
Cifrado
El procedimiento de reubicacion de SRNS se ha descrito en terminos de las etapas tomadas tanto en el sistema de UMTS como en la UTRAN. A partir de esta descripcion, es evidente que el procedimiento de reubicacion de SRNS esta basado principalmente en el intercambio de mensajes entre el terminal y el RNC, y entre el RNC y la red principal. Entre estos mensajes, los mensajes de RRC intercambiados entre el terminal y el RNC normalmente se cifran por motivos de seguridad.
En algunos casos, los mensajes de RRC cifrados no pueden descifrarse en el receptor puesto que los parametros de cifrado son diferentes entre el terminal y la UTRAN. Para obtener un mejor entendimiento de este problema, debe considerarse en primer lugar el procedimiento de cifrado en general.
El cifrado es un procedimiento que evita el acceso no autorizado de datos, por ejemplo, como resultado de una escucha clandestina. Puesto que existen parametros de cifrado unicos entre el terminal y el RNC, un usuario que no conoce los parametros 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 operacion del RLC. Es decir, cuando el modo de RLC es AM o UM, se realiza cifrado en la capa de RLC. Cuando el modo de RLC es TM, se realiza cifrado en la capa de MAC. Preferentemente, en este sistema se aplica cifrado unicamente para los canales de DCCH y DTCH.
Durante este procedimiento de cifrado, se genera una MASCARA usada para cifrado basandose en diversos parametros de entrada. La MASCARA se anade a continuacion a las PDU de RLC o a las SDU de MAC para generar los datos cifrados. En el terminal de usuario, se usa la misma MASCARA para descifrar los datos.
La Figura 8 muestra las etapas incluidas en el procedimiento de cifrado. En este punto, BLOQUE DE TEXTO PLANO son los datos antes del cifrado y BLOQUE DE FLUJO CLAVE es una MASCARA de cifrado. El BLOQUE DE TEXTO PLANO se cifra a BLOQUE DE TEXTO DE CIFRADO a traves de una operacion de bits con el BLOQUE DE FLUJO CLAVE. A continuacion, el BLOQUE DE TEXTO DE CIFRADO cifrado se transmite a una interfaz de radio. Despues de recibir el BLOQUE DE TEXTO DE CIFRADO, el receptor lo descifra aplicando el BLOQUE DE FLUJO CLAVE que es el mismo que la MASCARA como en el transmisor. Es decir, si los datos cifrados se extraen durante la transmision, los datos no pueden descifrarse a menos que se conozca el BLOQUE DE FLUJO CLAVE.
La tecnologfa principal de cifrado radica en la generacion del BLOQUE DE FLUJO CLAVE, es decir la MASCARA de cifrado. Para conseguir resultados eficaces, la MASCARA debena tener las siguientes caractensticas. En primer lugar, la generacion de la MASCARA mediante trazado inverso debena ser imposible. En segundo lugar, cada portadora de radio RB debena tener su propia MASCARA. En tercer lugar, la MASCARA debena cambiar continuamente con el tiempo.
Entre los diversos algoritmos de cifrado que existen, un procedimiento denominado como F8 se ha adoptado por los sistemas se comunicaciones del 3GPP. El algoritmo F8 genera el BLOQUE DE FLUJO CLAVE usando parametros de entrada que incluyen:
CK (clave de cifrado, 128 bits): hay una CKcs para un dominio de servicio basado en conmutacion de circuitos y una CKps para un dominio de servicio basado en conmutacion de paquetes.
PORTADORA (Identificador de Portadora de Radio, 5 bits): existe un valor para cada RB.
DIRECCION (Identificador de Direccion, 1 bit): indica la direccion de la RB. Se establece a 0 para enlace ascendente y 1 para enlace descendente.
LONGITUD (16 bits): indica la longitud del BLOQUE DE FLUJO CLAVE, es decir la MASCARA generada. RECUENTO-C (32 bits): un numero de secuencia de cifrado. Para las RB que usan RLC de AM o de UM, un RECUENTO-C se usa para cada RB. Para las RB que usan RLC de TM, se usa un valor de RECUENTO-C para todas las RB. Los expertos en la materia pueden apreciar que el bit y otros valores anteriormente proporcionados son valores preferidos y que pueden cambiarse si se desea.
Entre los parametros de entrada de cifrado, RECUENTO-C es el unico parametro que vana con el tiempo. Es decir, se usan diferentes valores de RECUENTO-C para cada PDU. Otros parametros de entrada de cifrado son parametros fijos y por lo tanto pueden usarse los mismos valores para estos parametros para todas las PDU en un flujo de datos. El parametro RECUENTO-C se divide en dos partes: una parte delantera y una parte trasera. La parte delantera incluye un numero de secuencia largo y la parte trasera incluye un numero de secuencia corto.
La Figura 9 muestra estructuras detalladas del parametro RECUENTO-C para los diversos modos de operacion de la capa de RLC. Las respectivas estructuras son como sigue:
5
10
15
20
25
30
35
40
45
50
Caso RLC de TM
- numero de secuencia largo: Numero de ^per Trama (HFN) de MAC-d de 24 bits
- numero de secuencia corto: Numero de Trama de Conexion (CFN) de 8 bits
Caso RLC de UM
- numero de secuencia largo: Numero de Hfper Trama (HFN) de RLC de 25 bits
- numero de secuencia corto: Numero de Secuencia (SN) de UM de RLC de 7 bits
Caso RLC de AM
- numero de secuencia largo: Numero de Hfper Trama (HFN) de RLC de 20 bits
- numero de secuencia corto: Numero 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 aumenta en uno por cada trama de radio (10 ms).
El SN de RLC es un numero de secuencia usado para identificar cada PDU de RLC. Para RLC de UM, el SN de RLC tiene un valor entre 0 y 127 (7 bits). Para RLC de AM, el SN de RLC tiene un valor entre 0 y 4095 (12 bits). El SN de RLC aumenta en 1 para cada PDU de RLC.
Puesto que un numero de secuencia corto es demasiado corto para usarse en solitario para RECUENTO-C, se anade un numero de secuencia largo conocido como HFN delante del numero de secuencia corto. Mas espedficamente, el HFN corresponde a los MSB (Bits Mas Significativos) y el numero de secuencia corto corresponde a los LSB (Bits Menos Significativos) del RECUENTO-C. Por lo tanto, HFN se aumenta en 1 cuando el numero de secuencia corto se ajusta alrededor de 0. El ajuste de este HFN es uno de los factores que produce que tengan lugar problemas de cifrado en sistemas de la tecnica relacionada, los detalles de los cuales se analizaran ahora.
Desventajas de los procedimientos de reubicacion de SRNS de la tecnica relacionada
Los problemas de cifrado se producen normalmente cuando los HFN se quedan fuera de sincronizacion entre las entidades de RLC del terminal y el RNS (o RNC) en la UTRAN. Este problema de sincronizacion es principalmente atribuible al parametro RECUENTO-C. Mas espedficamente, como se ha analizado anteriormente, todos los parametros de cifrados excepto RECUENTO-C son parametros fijos y por lo tanto permanecen sincronizados a lo largo de toda la conexion. El numero de secuencia corto (es decir los LSB del RECUENTO-C) esta tambien sincronizado puesto que, para RLC de TM, el CFN es conocido para tanto el terminal como la UTRAN y, para RLC de UM y de AM, el SN de RLC se incluye en el encabezamiento de la PDU y se transmite a traves de la interfaz de radio. Para RLC de TM, el numero de secuencia largo que corresponde al HFN esta tambien sincronizado puesto que el CFN se calcula a partir del SFN (Numero de Trama de Sistema) que se difunde continuamente en una celula. Para RLC de UM y de AM, sin embargo, el HFN en ocasiones esta fuera de sincronizacion debido a las PDU de RLC perdidas o retransmitidas. Esta condicion se explica en mayor detalle a continuacion.
Bajo condiciones normales, el HFN nunca se intercambia y se gestiona localmente mediante el terminal y la UTRAN. Los HFN gestionados localmente pueden quedarse fuera de sincronizacion para los modos de RLC de UM y de AM cuando se pierden o se re-transmiten las PDU de RLC, como se ha mencionado anteriormente. Si los valores de HFN gestionados mediante y el terminal y la UTRAN se hacen diferentes, entonces las MASCARAS usadas en el terminal y en la UTRAN se hacen tambien diferentes. Como resultado, los datos cifrados no pueden descifrarse en el receptor. Por lo tanto, una vez que los HFN se quedan fuera de sincronizacion, la transmision de datos no puede realizarse satisfactoriamente hasta que se sincronizan los HFN.
Los problemas en el procedimiento de reubicacion de SRNS de la tecnica relacionada se producen cuando surge este problema de cifrado (es decir, HFN no sincronizados) en una operacion de RLC de UM y de AM. En la Figura 7, estos problemas afectan a las etapas 7 y 8. La manera en la que estas etapas afectan de manera adversa se describira ahora en detalle. (Observese que la etapa 1 no tiene problema de cifrado puesto que el mensaje de RRC se transmite usando RLC de TM).
Problemas en la etapa 7.
En el Caso I (UE no implicado) y Caso II (UE implicado), los mensajes de RRC se transmiten al terminal usando una portadora de radio servidora SRB apropiada. La capa de RLC en el RNC objetivo se genera nuevamente y se inicializan las variables de estado y los temporizadores. Como resultado de esta inicializacion, el numero de secuencia de la PDU de RLC transmitida desde la capa de RLC en el RNC objetivo al terminal se inicializa a 0 (cero). La capa de RLC del terminal, sin embargo, puede esperar que la siguiente PDU que recibe tenga un numero de secuencia diferente. Los posibles problemas al transmitir mensajes de RRC resultantes de esta discrepancia se describiran para cada uno de estos casos.
5
10
15
20
25
30
35
40
45
50
55
60
(1) Mensaje de Informacion de Movilidad de UTRAN se transmite a traves de SRB1: en este caso, el procedimiento de reubicacion se realiza durante un modo de operacion de RLC de UM. Durante este procedimiento, el HFN de la UTRAN se transfiere desde el RNC de origen al RNC objetivo y el RNC objetivo transmite una unidad de datos de protocolo (PDU) que incluye el HFN de la UTRAN al terminal. Como se ha explicado anteriormente, sin embargo, antes de que la PDU se transmita, su numero de secuencia se inicializa a algun numero, por ejemplo, cero. En la mayona de los casos, este valor inicializado no corresponde al numero de secuencia de la siguiente PDU que el terminal espera recibir. Como resultado, cuando el terminal recibe la PDU con su numero de secuencia inicializado, concluye que una o mas PDU no se han recibido satisfactoriamente, por ejemplo, hay algunas PDU perdidas. El terminal operara por lo tanto basandose en la suposicion de que ha tenido lugar una condicion de vuelta al inicio de numero de secuencia de RLC. Cuando se detecta esta condicion, el RLC del transmisor modificara su informacion de cifrado aumentando su parametro de HFN en uno. Esto presenta el siguiente problema.
Cuando el procedimiento de reubicacion provoque que el RNS servidor (SRNS) cambie desde el RNC de origen al RNC objetivo, el valor del parametro de HFN no se cambio. Como resultado, el RNC objetivo transmitira las PDU con el valor de HFN de la UTRAN original. El terminal, sin embargo, intentara descifrar estas PDU con el valor de HFN nuevamente incrementado. Puesto que el terminal y la UTRAN estan operando basandose en diferentes valores de HFN, el terminal y la UTRAN (RNC objetivo) se considera que estan fuera de sincronizacion y el transmisor no podra descifrar ninguna PDU desde la UTRAN.
(2) Mensaje de Informacion de Movilidad de UTRAN se transmite a traves de SRB2: en este caso, el procedimiento de reubicacion se realiza durante el modo de operacion de RLC de AM, y el RLC del terminal unicamente acepta las PDU que tienen numeros de secuencia que caen dentro de un intervalo valido, que se mantiene para fines de gestion eficaz de re-transmisiones de datos. Este intervalo valido se define mediante el tamano y posicion de una ventana de recepcion mantenida mediante el receptor terminal durante la operacion de AM. Cuando el terminal recibe las PDU de RLC que radican fuera de la ventana de recepcion, el terminal simplemente descarta estas PDU.
Durante el procedimiento de reubicacion, la siguiente PDU transmitida al terminal tiene un numero de secuencia que se ha inicializado a cero. Si este numero de secuencia radica fuera de la ventana de recepcion del transmisor, se descartara inmediatamente. Sin embargo, incluso si el numero de secuencia radica dentro del intervalo de la ventana de recepcion, la PDU no podra descifrarse por el transmisor. Esto es debido a que el siguiente numero de secuencia que el terminal espera recibir no corresponde al numero de secuencia de la PDU recibida. El terminal concluira por lo tanto que existen PDU perdidas y que ha tenido lugar una condicion de vuelta al inicio con respecto a numeros de secuencia de PDU. Cuando se detecta esta condicion, el RLC de transmisor modificara su informacion de cifrado incrementando su parametro de HFN en uno, produciendo de esta manera que el HFN del terminal y el HFN de la UTRAN sean diferentes. Esta discrepancia evitara que el terminal descifre algun dato de la UTRAn
(3) Mensaje de Confirmacion de Actualizacion de Celula/URA se transmite a traves de SRB1: en este caso, el procedimiento de reubicacion se realiza durante operacion de RLC de UM. Tiene lugar el mismo problema como en (1) anteriormente, es decir, los mensajes de rRc transmitidos desde el RNC objetivo en la etapa 7 no pueden descifrarse por el terminal debido a una discrepancia en valores de HFN que tuvieron lugar como resultado de la inicializacion del numero de secuencia de la siguiente PDU transmitida desde la UTRAN.
En todos los casos anteriores, el terminal y la UTRAN no podran comunicar despues de que se haya realizado la reubicacion de SRNS a menos que y hasta que se resuelva el problema de fuera de sincronizacion con respecto a sus HFN. Se analizaran ahora las complicaciones que surgen en relacion con la etapa 8.
Problemas en la etapa 8.
En el Caso I (UE no implicado) y Caso II (UE implicado), el terminal transmite un mensaje de Confirmacion de Informacion de Movilidad de UTRAn a traves de SRB2 cuando se realiza el procedimiento de reubicacion durante el modo de operacion de RLC de AM. Los problemas similares tienen lugar 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.
En vista de las anteriores consideraciones, es evidente que existe una necesidad para un sistema y procedimiento mejorados para realizar un procedimiento de reubicacion de SRNS en un sistema de comunicaciones inalambricas, y mas espedficamente uno que resuelva de manera eficaz las discrepancias de descifrado que surgen entre entidades de transmision y de recepcion como resultado de una inicializacion realizada durante el procedimiento de reubicacion.
En el documento US 2002/0013147 A1 se transmite una informacion cifrada a traves de una primera ruta de comunicacion en modo de circuito entre una red principal y un terminal, pasando a traves de un primer controlador maestro, a continuacion a traves de una segunda ruta entre la red principal y el terminal, pasando a traves de un segundo controlador maestro. La segunda ruta se establece en un procedimiento que comprende la transmision de datos desde el primer al segundo controlador maestro, una fase de transmision simultanea de senales de radio mediante la infraestructura en la primera y segunda rutas, a continuacion la supresion de la primera ruta. Las senales de radio transmitidas en las dos rutas durante la fase de transmision simultanea transportan la misma informacion, se cifran con numeros de secuencia compensados, y el terminal de radio cambia desde la primera a la
5
10
15
20
25
30
35
40
45
50
55
segunda ruta mientras avanza el numero de secuencia de cifrado de tal manera como para alinearlo con el numero de compensacion usado mediante el segundo controlador.
“Universal Mobile Telecommunications System (UMTS); Interlayer procedures in Connected Mode (3GPP TS 25.303 version 3.9.0 Release 1999)”, ETSI Standards, European Telecommunications Standards Institute, Sophia Antipolis, FR, septiembre de 2001 (09-2001), documento XP014008610, describe en la seccion 6.4.8.2 un procedimiento de traspaso definitivo y reubicacion de SRNS para portadoras de radio sin perdidas.
Sumario de la invencion
Un objeto de la invencion es resolver al menos los anteriores problemas y/o desventajas y proporcionar al menos las ventajas descritas en lo sucesivo.
Otro objeto de la presente invencion es proporcionar un sistema y procedimiento para realizar un procedimiento de reubicacion de SRNS en un sistema de comunicaciones inalambricas de una manera en la que aumenta la eficacia de transmision en comparacion con otros sistemas que se han propuesto.
Otro objeto de la presente invencion es conseguir el objeto anteriormente mencionado resolviendo de manera eficaz las discrepancias de descifrado que surgen entre entidades de transmision y de recepcion cuando se realiza una etapa de inicializacion en el procedimiento de reubicacion.
Otro objeto de la presente invencion es resolver estas discrepancias de descifrado asegurando que las entidades de transmision y de recepcion operan usando el mismo parametro de HFN durante o inmediatamente despues de que se realiza el procedimiento de reubicacion. Coordinando esta informacion, se resuelve el problema de fuera de sincronizacion que otros sistemas propuestos experimentan. De acuerdo con una realizacion, la entidad de transmision puede ser un RNC de UTRAN y la entidad de recepcion puede ser un terminal de usuario, conocido de otra manera como equipo de usuario en las normas desarrolladas por el 3GPP, que incluyen pero sin limitacion el sistema universal de telecomunicaciones moviles (UMTS) que es una forma del sistema IMT-2000. En otra realizacion, la entidad de transmision puede ser el terminal de usuario y la entidad de recepcion puede ser un RNC de UTRAN. La presente invencion es tambien ventajosa puesto que puede aplicarse a modos de operacion de RLC de UM y de AM.
Los objetos se resuelven mediante las caractensticas de las reivindicaciones independientes. Se indican realizaciones adicionales en las reivindicaciones dependientes.
Los anteriores y otros objetos de la invencion se consiguen proporcionando un sistema y procedimiento que realizan la reubicacion de SRNS en un sistema de comunicacion movil, y mas espedficamente en un sub-sistema de red de radio servidor que incluye un controlador de red de radio para gestionar un recurso de radio asignado a un terminal en el sistema de comunicacion movil. De acuerdo con una realizacion, el procedimiento incluye reservar un recurso que se requiere en una reubicacion de sub-sistema de red de radio servidor en una red; transmitir un mensaje de control de recurso de radio que corresponde a la reubicacion del sub-sistema de red de radio servidor al terminal para que el controlador de red de radio comunique al terminal, y transmitir un mensaje de control de recurso de radio de respuesta que corresponde a la reubicacion del sub-sistema de red de radio servidor al controlador de red de radio al que se transmite el mensaje de control de recurso de radio.
El controlador de red de radio transmite datos estableciendo una capa de enlace de radio correspondiente y ajustando un numero de trama usado para cifrar de modo que el terminal restaura satisfactoriamente datos cifrados antes de que el controlador de red de radio transmita el correspondiente mensaje de control de recurso de radio al terminal. El numero de trama se aumenta en 1 mas que un valor usado en un tiempo actual, y unos datos de unidad de la correspondiente capa de enlace de radio se transmiten mediante cifrado. Una capa de control de recurso puede transmitir un comando para ajustar una capa de control de enlace y el numero de trama a la correspondiente capa de control de enlace de radio.
Ademas de estas etapas, un controlador de red de radio original puede realizar el papel de un controlador de red de radio servidor antes de que la reubicacion de sub-sistema de red de radio servidor transfiera la informacion de estado de una capa de control de enlace de radio usada en un momento actual a un controlador de red de radio objetivo. Esto se realiza de modo que el terminal recibe satisfactoriamente un mensaje de control de recurso de radio servidor antes de que el controlador de red de radio objetivo transmita un mensaje de control de recurso de radio que corresponde a la reubicacion del sub-sistema de red de radio servidor al terminal. La informacion de estado transferida puede incluir un parametro que corresponde a la capa de control de enlace de radio operada en un modo sin acuse de recibo. Tambien, se transmite un primer numero de secuencia de un dato de unidad de la capa de control de enlace de radio que incluye el mensaje de control de recurso de radio que corresponde a la reubicacion del sub-sistema de red de radio servidor transferido desde el controlador de red de radio objetivo al terminal estableciendose con un VT(US) de un parametro que corresponde la capa de control de enlace de radio operada en el modo sin acuse de recibo.
De acuerdo con otra realizacion, la informacion de estado transferida incluye un parametro o dato que corresponde a la capa de control de enlace de radio operada en un modo de acuse de recibo. Tambien, se transmite un primer
5
10
15
20
25
30
35
40
45
50
55
numero de secuencia de datos de unidad de la capa de control de enlace de radio que incluye el mensaje de control de recurso de radio que corresponde a la reubicacion del sub-sistema de red de radio servidor transferido desde el controlador de red de radio objetivo al terminal estableciendose con un VT(US) de un parametro que corresponde a la capa de control de enlace de radio z operada en el modo sin acuse de recibo. La capa de control de enlace de radio del controlador de red de radio objetivo puede transmitir datos de unidad de la capa de control de enlace de radio que se estan transmitiendo que se transfieren desde el controlador de red de radio original.
El controlador de red de radio original finaliza la transmision del mensaje de control de recurso de radio que se esta transmitiendo o que esta esperando para transmitirse antes de transferir el parametro que corresponde a la capa de control de enlace de radio operada en el modo con acuse de recibo.
La capa de control de enlace de radio del controlador de red de radio objetivo transmite un comando de movimiento de ventana de recepcion a una capa de control de enlace de radio del terminal para evitar una transmision de un dato de unidad de la capa de control de enlace de radio que tiene un numero de secuencia por debajo de un numero de secuencia de VT(S)-1. La capa de control de recurso de radio del controlador de red de radio objetivo indica a la capa de control de enlace de radio que inicie el comando de movimiento de ventana de recepcion para transmitir el comando de movimiento de ventana de recepcion.
En las realizaciones anteriores, la capa de control de recurso de radio transfiere el parametro o los datos transferidos desde el controlador de red de radio original a la capa de control de enlace de radio. Tambien, 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 recurso de radio transmitido desde el controlador de red de radio objetivo al terminal despues de que la reubicacion del sub-sistema de red de radio servidor indica una informacion de que los datos de unidad del correspondiente control de enlace de radio incluyen el mensaje de control de recurso de radio desde una primera porcion del mismo.
Ademas de estas caractensticas, una cualquiera o mas de las realizaciones de la presente invencion puede incluir una etapa de inicializacion para la capa de control de enlace de radio, donde se inicializa una variable de estado y se sincroniza un numero 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 de radio objetivo. Esto posibilitara que el terminal reciba satisfactoriamente el mensaje de control de recurso de radio antes de que el controlador de red de radio objetivo transmita el mensaje de control de recurso de radio que corresponde a la reubicacion del sub-sistema de red de radio servidor al terminal. El controlador de red de radio objetivo puede transmitir un dato de unidad inicial a la capa de control de enlace de radio del terminal como un comando que realiza una inicializacion del control de enlace de radio.
Ademas, la capa de control de recurso de radio del controlador de red de radio objetivo puede transferir un comando de inicio de inicializacion a la capa de control de enlace de radio para que la capa de control de enlace de radio del controlador de radio objetivo inicie un procedimiento de inicializacion de la capa de control de enlace de radio.
Las capas de control de enlace de radio del controlador de red de radio objetivo y el terminal se establecen preferentemente para permitir al controlador de red de radio objetivo recibir satisfactoriamente el correspondiente mensaje de control de recurso de radio antes de que el terminal transmita el mensaje de control de recurso de radio que corresponde a la reubicacion del sub-sistema de red de radio servidor al controlador de red de radio objetivo. En este punto, un numero de trama puede sincronizarse durante el ajuste de las capas de control de enlace de radio del controlador de red de radio objetivo y el terminal. Un ajuste del numero de trama puede transferirse desde una capa superior, y puede realizarse aumentando los numeros de trama usados en el terminal y en el controlador de red de radio objetivo en 1 (uno). Como alternativa, el ajuste del numero de tramas usadas 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 de radio objetivo puede realizarse aumentando un valor mayor entre un numero de trama de enlace ascendente y un numero de trama de enlace descendente usados 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 de radio objetivo en 1 (uno) basandose en el valor mayor.
Las capas de control de recurso de radio del terminal y el controlador de red de radio objetivo transmiten respectivos comandos para un ajuste/reajuste de las correspondientes capas de control de enlace de radio.
Se realiza un ajuste/reajuste de una portadora de radio de senalizacion y una portadora de radio en el terminal y en el controlador de red de radio objetivo despues de un procedimiento que el terminal transmite un mensaje de control de recurso de radio de respuesta que corresponde a la reubicacion del sub-sistema de red de radio servidor al controlador de red de radio objetivo. En este punto, un numero de trama en el ajuste/reajuste de la portadora de radio de senalizacion y en la portadora de radio entre el terminal y el controlador de red de radio objetivo se establece a un valor inicial de numero de trama incluido en el mensaje de control de recurso de radio de respuesta que corresponde a la reubicacion del sub-sistema de red de radio servidor transmitida desde el terminal al controlador de red de radio objetivo. El valor inicial de numero de trama incluido en el mensaje de control de recurso de radio puede corresponder a un valor inicial almacenado en un modulo de cifrado del terminal definido en una norma del Sistema Universal de Telecomunicaciones Moviles del sistema IMT2000 asmcrono.
5
10
15
20
25
30
35
40
45
50
55
Se expondran ventajas, objetos y caractensticas adicionales de la invencion en parte en la descripcion que sigue y en parte seran evidentes para los expertos en la materia tras la examinacion de lo siguiente o puede aprenderse a partir de la practica de la invencion. Los objetos y ventajas de la invencion pueden realizarse y conseguirse como se senala particularmente en las reivindicaciones adjuntas.
Breve descripcion de los dibujos
La invencion se describira en detalle con referencia a los siguientes dibujos en los que numeros de referencia similares se refieren a elementos similares en los que:
La Figura 1 muestra una arquitectura de red de un Sistema Universal de Telecomunicaciones Moviles (UMTS);
La Figura 2 muestra una estructura de un protocolo de interfaz de radio que puede implementarse en el sistema de UMTS;
La Figura 3 muestra una estructura de una Unidad de Datos de Protocolo (PDU) usada en una capa del Control de Enlace de Radio (RLC) del protocolo de interfaz de radio de la Figura 2;
La Figura 4 es una instantanea ejemplar del estado de una memoria intermedia de RLC de AM;
La Figura 5 es un diagrama que ilustra el concepto de un procedimiento de Reubicacion de SRNS;
La Figura 6 es un procedimiento de senalizacion de Reubicacion de SRNS en el sistema de UMTS;
La Figura 7 es un procedimiento de senalizacion de Reubicacion de SRNS de un sistema de la tecnica relacionada que incluye una Red de Acceso de Radio Terrestre de UMTS (UTRAN);
La Figura 8 muestra un procedimiento de cifrado realizado en el protocolo de interfaz de radio de la Figura 2;
La Figura 9 es la estructura del parametro RECUENTO-C usado en el modo de RLC;
La Figura 10 es un diagrama de flujo que muestra etapas incluidas en una serie de realizaciones del procedimiento de la presente invencion identificadas como A1 y A2 para realizar un procedimiento de reubicacion de SRNS;
La Figura 11 es un diagrama de flujo que muestra etapas incluidas en una serie de realizaciones del procedimiento de la presente invencion identificadas como B1 y B2 para realizar un procedimiento de reubicacion de SRNS;
La Figura 12 es un diagrama de flujo que muestra etapas incluidas en una serie de realizaciones del procedimiento de la presente invencion identificadas como C1, C2, y C3 para realizar un procedimiento de reubicacion de SRNS;
La Figura 13 es un diagrama de flujo que muestra etapas incluidas en una realizacion del procedimiento de la presente invencion que realiza la reubicacion de SRNS para el caso de portadoras de radio sin perdidas; y La Figura 14 es un diagrama de flujo que muestra etapas incluidas en una realizacion del procedimiento de la presente invencion que realiza la reubicacion de SRNS para el caso de portadoras de radio sin interrupcion.
Descripcion detallada de realizaciones preferidas
La presente invencion es un sistema y procedimiento para realizar un procedimiento de reubicacion de SRNS en un sistema de comunicaciones inalambricas. El procedimiento de reubicacion se realiza de tal manera que evita que surja una condicion de fuera de sincronizacion entre entidades de transmision y de recepcion. En una realizacion, la invencion sincroniza informacion de cifrado en las entidades de transmision y de recepcion. Tomando estas etapas, la presente invencion mejora la fiabilidad y eficacia de las comunicaciones en el sistema. Aunque la invencion es adecuada para uso en un sistema de UMTS, los expertos en la materia pueden apreciar que el procedimiento puede realizarse en sistemas de comunicacion que se adhieren a otras normas y/o protocolos.
El procedimiento de la presente invencion controla la manera en la que se transmite la informacion entre un receptor y un transmisor, y es especialmente bien adecuada para uso en la aplicacion no limitante de en donde el transmisor es una UTRAN y el receptor es un terminal de usuario (o equipo de usuario como se denomina por la iniciativa del 3GPP). Cuando se aplica de esta manera, las etapas del procedimiento pueden diferenciarse dependiendo del tipo de la reubicacion de SRNS a realizar y del modo de operacion de las capas de RLC de la UTRAN y del terminal de usuario.
El procedimiento de reubicacion de SRNS puede clasificarse en dos casos. En el Caso I, la reubicacion de SRNS se inicia mediante la red principal u otra y el terminal no esta informado de que se realiza la reubicacion hasta que se termina el procedimiento de reubicacion. El Caso I puede estar caracterizado por lo tanto como que corresponde a la situacion donde el terminal no esta implicado en tomar la decision para realizar la reubicacion. En el Caso II, la reubicacion de SRNS se inicia mediante el terminal de usuario. El terminal es conocedor por lo tanto de que se esta realizando la reubicacion en el mismo inicio del procedimiento. El Caso II puede estar caracterizado por lo tanto como que corresponde a la situacion donde el terminal esta implicado en tomar la decision para realizar la reubicacion de SRNS.
Las diversas realizaciones del procedimiento de la presente invencion pueden entenderse inicialmente distinguiendolas del procedimiento de la tecnica relacionada de la Figura 7. Aunque la presente invencion puede compartir alguna de las etapas en el procedimiento de la tecnica relacionada, el siguiente analisis hace evidente que la presente invencion supera ventajosamente la sincronizacion y otros problemas que surgen en este sistema. Se proporcionara inicialmente por lo tanto una descripcion del sistema de la tecnica relacionada.
5
10
15
20
25
30
35
40
45
50
55
Haciendo referencia a la Figura 7, se diferencia una etapa inicial del procedimiento dependiendo de si el procedimiento de reubicacion 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 invencion empieza cuando la red decide realizar la reubicacion de SRNS, es decir, cuando la UTRAN decide cambiar desde un rNs (o un RNC de origen) a otro RNS (o un RNC objetivo) para fines de comunicacion con el terminal de usuario. (Etapa 2). La red puede decidir realizar una reubicacion de SRNS basandose en uno cualquiera de una diversidad de factores. Por ejemplo, puede ser deseable la reubicacion para reducir la cantidad de trafico que se esta manejado por el RNC de origen, para ubicar una ruta de comunicaciones mas corta o mas eficaz para fines de manejar una llamada con el terminal de usuario, u otras razones que pueden entenderse por los expertos en la materia.
En el Caso II, el procedimiento de la presente invencion empieza cuando el terminal de usuario transmite un mensaje de RRC en forma de un mensaje de Actualizacion de Celula/URA al RNC de origen. (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 mueve a una nueva celula en el sistema inalambrico, por ejemplo, cuando una operacion de traspaso es inminente o se requiere. En este momento, la red puede decidir si responder favorablemente satisfaciendo la solicitud o puede responder inmediatamente.
La segunda a quinta etapas se realizan comunmente para los Casos I y II. En la segunda etapa, se realiza la preparacion de reubicacion. (Etapa 3). Esto implica reenviar parametros relevantes para comunicar con el terminal de usuario desde el RNC de origen al RNC objetivo a traves de un contenedor de informacion de RRC. Este contenedor incluye, por ejemplo, informacion de cifrado (por ejemplo, parametros de HFN de enlace descendente y de HFN de enlace ascendente) para portadoras de radio de senalizacion, asf como recursos de radio que incluyen nuevas RAB para fines de cambiar el RNS servidor desde el RNC de origen al RNC objetivo. El tipo de portadoras de radio reservadas en esta etapa depende de si se esta soportando el modo de RLC de AM o de Um en la UTRAN. Si se soporta el modo AM, se reserva una o mas portadoras de radio sin perdidas de modo que puede realizarse la reubicacion de SRNS sin perdidas. Si se soporta el modo UM, se reserva una o mas portadoras de radio sin interrupciones de modo que puede realizarse la reubicacion de SRNS sin interrupciones.
La tercera etapa incluye recibir un Comando de Reubicacion de RANAP desde la red principal, y mas espedficamente desde un SGSN existente en la red principal. (Etapa 4). El SGSN existente puede denominarse como el “antiguo SGSN”, y si la reubicacion da como resultado requerir un cambio de SGSN (que puede no ser siempre el caso) se asignara un “nuevo SGSN” despues de la reubicacion. El Comando de Reubicacion informa al RNC de origen de las RAB a liberar y las RAB que se someten a reenvfo de datos en relacion con el procedimiento de reubicacion. Puede configurarse el SRNC sin perdidas (realizado para operacion de RLC de AM) para las RAB sometidas a reenvfo de datos. La capa de PDCP soporta numeracion de secuencia de PDCP cuando se soporta reubicacion de SRNS sin perdidas.
La cuarta etapa incluye transmitir un mensaje de Compromiso de Reubicacion desde el RNC de origen al RNC objetivo. (Etapa 5). En esta etapa, para las portadoras de radio afectadas, el RLC de origen se detiene y se recuperan los numeros de secuencia de transmision de PDCP mediante el RRC. El PDCP del RNC de origen transfiere los numeros de secuencia y otra informacion para comunicar con el terminal de usuario al RNC objetivo.
La quinta etapa incluye transmitir un mensaje de Deteccion de Reubicacion de RANAP desde el RNC objetivo al RNC de origen. (Etapa 6). Cuando este mensaje se recibe, el RNC objetivo se hace el RNC servidor. Puede realizarse un cambio correspondiente desde el antiguo SGSN al nuevo SGSN en este momento. Despues de estas etapas, ha tenido lugar la reubicacion.
La sexta etapa incluye transmitir un mensaje de RRC desde el RNC objetivo al terminal de usuario, y mas espedficamente a la capa de RRC del terminal de usuario. En el Caso I, el mensaje de RRC es en forma de un mensaje de Informacion de Movilidad de UTRAN. En el Caso II, el mensaje de RRC es en forma de un mensaje de Confirmacion de Actualizacion de Celula/URA. En cada uno de estos mensajes, se incluye una nueva U-RNTI para informar al terminal de usuario que se realizo un procedimiento de reubicacion de SRNS.
Una septima etapa incluye calcular un valor de INICIO en el terminal de usuario en respuesta a la informacion de sincronizacion de contador de enlace descendente. El valor de INICIO se transmite a continuacion desde el terminal de usuario a la capa de RRC del RNC objetivo en un mensaje de RRC denominado un mensaje de Confirmacion de Informacion de Movilidad de UTRAN. (Etapa 7).
Una octava etapa incluye establecer entidades de RLC en el RNC objetivo basandose en el valor de INICIO incluido en el mensaje de Confirmacion de Informacion de Movilidad de UTRAN. Mientras tanto, el terminal de usuario puede re-establecer tambien sus entidades de RLC con el valor de INICIO transmitido. (Etapa 8).
La descripcion anterior puede servir como una estructura para el enfoque tomado por el procedimiento de la presente invencion para superar el problema de fuera de sincronizacion que afecta adversamente al rendimiento del procedimiento de la tecnica relacionada de la Figura 7. Este problema tiene lugar en la sexta etapa analizada anteriormente.
5
10
15
20
25
30
35
40
45
50
55
60
En esta etapa, el RNC objetivo transmite un mensaje de RRC en cualquiera de SRB1 o SRB2 dependiendo del caso y del modo de operacion de las entidades de RLC. Mas espedficamente, cualquiera de un mensaje de Informacion de Movilidad de UTRAN se envfa en un AM/DCCH (SRB2) o UM/DCCH (SRB1), o se envfa un mensaje de Confirmacion de Actualizacion de Celula/URA en UM/DCCH (SRB1). Aunque el mensaje de Confirmacion de Actualizacion de Celula/URA puede usar UM/CCCH (SRB0), la polftica de reubicacion de SRNS (si el SRNS se reubica antes de que se envfe la confirmacion de Actualizacion de Celula/URA, debena usarse un DCCH para permitir el cifrado de los contenidos del mensaje) puede requerir que este mensaje no debiera usar SRB0 en el caso de la reubicacion de SRNS.
Cuando se realizan las etapas mostradas en la Figura 7, surgen problemas de fuera de sincronizacion entre el terminal de usuario y la UTRAN que evita que se realicen las comunicaciones. Algunos de estos problemas tienen lugar como sigue.
Problema 1: se envia mensaje de RRC de CL en SRB1 (UM/DCCH). Antes de la reubicacion de SRNS, el RNC de origen puede estar comunicando PDU con el terminal de usuario basandose en informacion de descifrado sincronizada. Por ejemplo, el RNC de origen puede transmitir PDU basandose en un parametro de HFN de enlace descendente = X y un numero de secuencia de transmision que corresponde a una variable de estado VT(US) = 50 para modo de operacion de UM. De manera similar, el terminal de usuario puede transmitir PDU basandose en un HFN de enlace ascendente = X y un VR(US) = 50. Puesto que la informacion de descifrado y la transmision de numeros de secuencia estan sincronizadas, el terminal de usuario y el RNC de origen pueden comunicar sin problemas. Sin embargo, cuando tiene lugar la reubicacion de SRNS, puesto que el valor de HFN se transfiere desde el RNC de origen al objetivo sin ninguna informacion adicional (por ejemplo, sin transmision de informacion de numero de secuencia en forma de una o mas variables de estado VT(US) o VR(US)), el RNC objetivo establece una entidad de RLC de UM con la misma informacion de descifrado usada mediante el RNC de origen (es decir, HFN de DL = X) pero con la variable de estado VT(US) establecida a un valor nuevamente inicializado, por ejemplo, cero.
Por consiguiente, cuando el RNC objetivo envfa un mensaje de RRC al terminal de usuario, el terminal de usuario reconocera en la mayona de los casos el numero de secuencia de transmision en el mensaje de RRC como que corresponde a un numero fuera de secuencia, puesto que no incluye el numero de secuencia que sigue a la ultima PDU transmitida mediante el RNC de origen. Cuando esto tiene lugar (por ejemplo, cuando el terminal de usuario detecta que el mensaje de RRC recibido tiene un numero de serie SN = 0), concluira que se ha recibido una nueva PDU y mas espedficamente que las PDU que tienen numeros de serie de entre 50 y 127 se han perdido. Como resultado, el terminal de usuario aumentara su HFN a un valor de X + 1 para fines de descifrar futuras PDU. Sin embargo, el RNC objetivo continuara transmitiendo PDU basandose en HFN = X. Puesto que hay una discrepancia en la informacion de descifrado usada por el terminal de usuario y el RNC objetivo, el terminal de usuario no podra descifrar y por lo tanto recibira satisfactoriamente las PDU transmitidas desde el RNC objetivo. Esto significa que el terminal de usuario no puede recibir el mensaje de RRC.
Problema 2: se envia mensaje de RRC de DL en la SRB2 (AM/DCCH). Antes de la reubicacion de SRNS, se supone que HFN de DL = X y VT(S) = 3000 en el RNC de origen y HFN de DL = X y VR(R) = 3000 en el terminal de usuario. Puesto que la informacion de descifrado y los numeros de secuencia de transmision estan sincronizados, el terminal de usuario y el RNC de origen pueden comunicar satisfactoriamente. Sin embargo, cuando tiene lugar la reubicacion de SRNS, puesto que el valor de HFN se transfiere desde el RNC de origen al RNC objetivo sin VT(S) indicativa de numero de secuencia de transmision, el RNC objetivo establecera una entidad de RLC de AM con HFN de DL = X pero con VT(S) establecida a un valor inicial, por ejemplo, VT(S) = 0.
Cuando el mensaje de RRC se envfa desde el RNC objetivo al terminal de usuario, el terminal de usuario descartara el mensaje si su numero de secuencia de transmision (que es cero en este caso) radica fuera del intervalo de la ventana de recepcion. Sin embargo, incluso si el numero de secuencia del mensaje de RRC radica en la ventana de recepcion, el terminal de usuario considerara que es una nueva PDU, es decir, que las PDU que tienen numeros de secuencia de 3000-4095 se han perdido. Cuando esto tiene lugar, el terminal de usuario establece su HFN = X + 1. Como resultado, la informacion de descifrado en el terminal de usuario y en el RNC objetivo son diferentes y por lo tanto el terminal de usuario no podra recibir el mensaje de RRC transmitido desde el RNC objetivo.
En ambos problemas analizados anteriormente (SRB1 o SRB2), el terminal de usuario en la mayona de los casos no puede recibir el mensaje de RRC transmitido desde el RNC objetivo. Como resultado, la reubicacion de SRNS falla. Por supuesto, se observa que hay una pequena posibilidad de que el terminal de usuario podra recibir el mensaje de RRC inicial desde el RNC objetivo, pero esto unicamente puede suceder cuando VT(US) = VR(US) = 0 o VT(S) = VR(R) = 0. Sin embargo, incluso si el mensaje de RRC inicial desde el RNC objetivo se recibe satisfactoriamente y se descifra mediante el terminal de usuario, el RNC objetivo no podra recibir el mensaje de RRC de Confirmacion de Informacion de Movilidad de UTRAN transmitido desde el terminal de usuario. Este mensaje se envfa en AM/DCCH (SRB2), y no puede recibirse mediante el RNC objetivo puesto que VT(S) = 3000 en el terminal de usuario pero VR(R) = 0 en el RNC objetivo.
El sistema y procedimiento de la presente invencion superan estos y otros problemas que surgen en el sistema de la tecnica relacionada como resultado de desajustes de sincronizacion y de numero de secuencia de transmision. Como reflejaran las siguientes realizaciones, el RNC objetivo y terminal de usuario se controlaran para sincronizar
5
10
15
20
25
30
35
40
45
50
55
toda la informacion requerida para que se realice un procedimiento de reubicacion satisfactorio. Las realizaciones espedficas se analizaran ahora.
El procedimiento de la presente invencion puede realizarse de manera diferente dependiendo de si se aplica el Caso I o el Caso II. Cuando se solicita la reubicacion de SRNS mediante la red (Caso I), la sexta etapa incluye sincronizar informacion de cifrado en el RNC objetivo a informacion de cifrado que se espera usarse en el terminal de usuario. Esta sincronizacion puede realizarse en vista de la siguiente realizacion.
Durante el procedimiento de reubicacion, las PDU de RLC transmitidas desde el RNC objetivo al terminal de usuario tendran valores inicializados. Por ejemplo, a la primera PDU transmitida se le proporcionara un numero de secuencia de transmision inicial tal como cero. En el lado del terminal de usuario, la capa de RLC recibe las PDU y las ordena basandose en el numero de secuencia de transmision. Puesto que el terminal de usuario estaba comunicando con el RNC de origen antes de la reubicacion, la siguiente PDU que el RLC del terminal de usuario espera recibir es una cuyo numero de secuencia de transmision sigue consecutivamente el numero de secuencia de transmision de la ultima PDU recibida. La primera PDU transmitida desde el RNC objetivo en la UTRAN, sin embargo, tendra un numero de secuencia inicializado y por lo tanto con toda probabilidad no corresponded al numero esperado.
Cuando esto tiene lugar una vez o un numero predeterminado de veces, el RLC del terminal de usuario concluira que ha tenido lugar una condicion de vuelta al inicio. Cuando se detecta una condicion de este tipo, el RLC del terminal de usuario ajustara su informacion de descifrado cambiando su parametro de HFN a un nuevo valor. Este cambio puede implicar incrementar el parametro de HFN en 1.
En el procedimiento de la tecnica relacionada de la Figura 7, el RNC objetivo no compenso este cambio en la informacion de descifrado en el terminal de usuario. En su lugar, las PDU se cifraron usando informacion de cifrado (es decir, el parametro de HFN) incluido en el contenedor de informacion de RRC enviado desde el RNC de origen al RNC objetivo. Como resultado, las PDU transmitidas desde el RNC objetivo no pudieron descifrarse por el terminal de usuario y ocurrio una perdida en las comunicaciones.
La presente invencion supera este problema tomando uno de varios enfoques. Un enfoque implica ajustar informacion de cifrado en el RNC objetivo recibida desde el RNC de origen. Este ajuste asegura que el RNC objetivo cifra las PDU con el mismo parametro de HFN que el terminal de usuario usara durante el descifrado. Puesto que el software de gestion de la UTRAN esta programado para conocer como el terminal de usuario ajustara su parametro de HFN cuando se recibe una PDU que tiene un numero de secuencia de transmision fuera de secuencia, el RNC objetivo puede cifrar las PDU para enviarse al terminal de usuario usando el mismo parametro de HFN ajustado. La naturaleza del ajuste realizado por la presente invencion depende de si se esta observando el Caso I o el II y si los RLC del terminal de usuario y los RNC objetivos estan operando en un modo de AM o de UM. Se aplican las siguientes situaciones.
A. Un mensaje de RRC de enlace descendente enviado en SRB1 (UM/DCCH).
En este caso, los RLC del RNC objetivo y el terminal de usuario estan operando en modo de UM. El RNC objetivo envfa un mensaje de RRC en una portadora de radio servidora SRB1 (que corresponde a un canal de DCCH de UM) al terminal de usuario. Se aplican las siguientes situaciones.
A.1. RNC objetivo establece SRB1 e incrementa HFN de DL.
Haciendo referencia a la Figura 10, el RNC objetivo recibe un contenedor de informacion de RRC desde el RNC de origen. El contenedor incluye informacion de cifrado que incluye preferentemente un parametro de HFN que el RNC de origen estaba usando para comunicar con el terminal de usuario. Cuando se recibe el contenedor de informacion de RRC, el RNC objetivo incrementa el parametro de HFN y establece una nueva SRB1. Puesto que el RNC objetivo sabe de antemano la manera en la que el terminal de usuario cambia su parametro de HFN cuando tiene lugar una condicion de vuelta al inicio o cuando se recibe una PDU fuera de secuencia, el RNC objetivo incrementa su parametro de HFN de una manera identica. Como resultado, las PDU generadas por el RNC objetivo se cifraran de una manera que es descifrable por el terminal de usuario.
Una vez que se han generado las PDU, se transmiten desde un RLC de UM del RNC objetivo al terminal de usuario. La primera PDU transmitida incluye un numero de secuencia de transmision inicial, por ejemplo, SN = 0. Cuando el terminal de usuario recibe las PDU, el terminal de usuario detecta que la primera PDU tiene un numero de secuencia de transmision fuera de secuencia. El terminal de usuario puede realizar esta funcion de deteccion extrayendo variables de estado VR(US) desde la primera PDU. Puesto que esta variable de estado proporciona una indicacion del numero de secuencia de transmision que corresponde a esta PDU, puede detectarse una condicion de vuelta al inicio o de fuera de secuencia. Por ejemplo, en el caso donde VR(US) tiene valores de 0 a 127, el terminal de usuario puede determinar que las PDU que tienen el valor del VR(US) en la PDU recibida hasta el numero de VR 127 se han perdido.
Cuando se detecta esta condicion, el terminal de usuario ajustara su parametro de HFN, por ejemplo, incrementando este parametro en 1. Puesto que las PDU transmitidas desde el RNC objetivo se generaron y transmitieron de acuerdo con este mismo parametro de HFN, las PDU pueden descifrarse y las comunicaciones pueden tener lugar a
5
10
15
20
25
30
35
40
45
50
55
pesar del procedimiento de reubicacion. Sincronizando la informacion de cifrado en el terminal de usuario y en el RNC objetivo, la presente invencion supera ventajosamente el problema de fuera de sincronizacion que tiene lugar en el sistema de la tecnica relacionada de la Figura 7.
Una etapa opcional pero deseable implica incluir un indicador de inicio de datos (que puede denominarse como Especial L1) en una o mas PDU transmitidas desde el RNC objetivo al terminal de usuario. De acuerdo con la presente invencion, el indicador de inicio de datos puede incorporarse en las PDU transmitidas mediante el RNC objetivo a traves de un canal de DCCH de UM. La inclusion 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 la PDU que es parte de una SDU anterior y puede simplemente descartarla. Cuando se recibe mediante el terminal de usuario, el indicador de inicio de datos se interpretara para indicar que la PDU a la que esta unido no es parte de una SDU anterior. Incluyendo este indicador se asegurara por lo tanto que las PDU recibidas desde el RNC objetivo no se descartaran. Para maximizar la eficacia de transmision, la primera PDU transmitida desde el RNC objetivo (es decir, la PDU que tiene un numero de secuencia de transmision SN = 0) incluye preferentemente el indicador Especial L1.
A. 2. RNC de origen transfiere VT(US) a RNC objetivo.
Este enfoque se diferencia del enfoque en A.1. en que en lugar de incrementar su parametro de HFN, la primera PDU transmitida desde el RNC objetivo al terminal de usuario contiene el siguiente numero de secuencia de transmision que el terminal de usuario espera recibir. Por lo tanto, el parametro de HFN usado por el RNC objetivo y terminal de usuario permanece sincronizado y por lo tanto pueden realizarse comunicaciones de datos. Se proporcionara ahora una descripcion mas detallada de este enfoque.
En una etapa inicial, el RNC de origen entrega un contenedor 50 de informacion de RRC que incluye la variable de estado VT(US) de la portadora de radio servidora SRB1 al RNC objetivo. La variable de estado VT(US) es indicativa de un numero de secuencia de transmision relacionado con el numero de secuencia de transmision de la ultima o una de las ultimas PDU transmitidas desde el RNC de origen al terminal de usuario. El RNC objetivo usa la variable de estado VT(US) como una base para transmitir su primera PDU 60 al terminal de usuario. Por ejemplo, si VT(US) corresponde al ultimo numero de secuencia transmitido, el RNC objetivo puede incrementar el numero de secuencia de transmision que corresponde a VT(US) en uno y a continuacion transmitir la primera PDU que contiene este valor. Cuando el terminal de usuario recibe esta PDU, detectara que esta PDU tiene el siguiente numero en la secuencia que espera y por lo tanto no se detectara condicion de vuelta al inicio o de PDU perdida. Como resultado, el terminal de usuario no incrementara su valor de HFN como en el caso anterior; y puesto que la PDU se cifro basandose en el mismo valor de HFN, el terminal de usuario podra descifrarla.
Como una alternativa a este enfoque, la variable VT(US) entregada desde el RNC de origen al RNC objetivo puede ser el siguiente numero en la secuencia que el equipo de usuario espera recibir. En este caso, el RNC objetivo transmitira la primera PDU con el numero que corresponde a VT(US).
Este enfoque puede incluir un numero de etapas adicionales. En primer lugar, puede usarse un nuevo IE (elemento de informacion) a la luz de la adicion de VT(US) de SRB1 en el contenedor de informacion de RRC.
En segundo lugar, la etapa de establecimiento de RLC puede modificarse. Por ejemplo, cuando se establece la entidad de RLC, todas las variables de estado pueden establecerse a valores iniciales (por ejemplo, 0). Como resultado, puede no ser posible establecer la entidad de RLC de UM con VT(US) distinta de 0. Para compensar el ajuste de las variables de estado a valores iniciales, debena realizarse un procedimiento de establecer y modificar. Es decir, en primer lugar, se establece la entidad de RLC con todas las variables de estado para que sean 0, en segundo lugar, las variables de estado se modifican para que sean valores deseados.
En tercer lugar, debena incluirse un indicador de inicio de datos (por ejemplo, Iniciar LI) en la primera PDU de UM transmitida desde el RNC objetivo al terminal de usuario. Si la primera PDU se transmite sin este indicador y si, por ejemplo, la PDU con numero de secuencia SN = VT(US) - 1 se pierde, el equipo de usuario descartara la pDu. Puesto que el equipo de usuario considera que la PDU contiene sDu incompleta una porcion de la cual puede estar contenida en la primera PDU. Incluir el indicador de inicio de datos en la primera PDU transmitida desde el RNC objetivo garantizara por lo tanto que el mensaje de RRC se recibira por el terminal de usuario.
B. Mensaje de RRC de enlace descendente enviado en SRB2 (AM/DCCH).
En este caso, los RLC del RNC objetivo y del terminal de usuario estan operando en modo de AM. El RNC objetivo envfa un mensaje de RRC en una portadora de radio servidora SRB2 (que corresponde a un canal de DCCH de AM) al terminal de usuario.
B.1. El RNC objetivo establece SRB2 e inicializa procedimiento de RESETEO de RLC
Haciendo referencia a la Figura 11, antes de enviar el mensaje de RRC, el RNC objetivo realiza una operacion de RESETEO de RLC que implica reajustar el numero de secuencia de transmision y variables de estado a valores iniciales. Preferentemente al mismo tiempo, el RNC objetivo transmite una PDU 70 de Reseteo al terminal de
5
10
15
20
25
30
35
40
45
50
55
usuario. De acuerdo con un aspecto de la invencion, la PDU de Reseteo se transmite sin cifrar y no tiene numero de secuencia de transmision. En consecuencia, el terminal de usuario podra recibir la PDU de Reseteo transmitida a traves de SRB2. Tras recibir la PDU de reseteo, el terminal de usuario reseteara sus variables de estado y numero de secuencia de transmision a los mismos valores iniciales establecidos en el RNC objetivo.
Puesto que la PDU de Reseteo no tiene numero de secuencia de transmision, el terminal de usuario no detectara una condicion de vuelta al inicio o de fuera de secuencia cuando se recibe la PDU de Reseteo. Por lo tanto, el parametro de HFN en el terminal de usuario no se incrementara. Como resultado, el parametro de HFN que el RNC objetivo recibio desde el RNC de origen y el parametro de HFN del terminal de usuario seran el mismo. Y puesto que las variables de estado y los numeros de secuencia de transmision del RNC objetivo y del terminal de usuario se han inicializado a valores similares, el RNC objetivo y terminal de usuario pueden comunicarse satisfactoriamente entre sf. Cuando se completa el reseteo en el terminal de usuario, se transmitira una PDU 80 de ACK de Reseteo de mensaje de acuse de recibo de reseteo desde el terminal de usuario al RNC objetivo.
Como una alternativa a esta realizacion, la operacion de Reseteo realizada en el RNC objetivo puede provocar que se incremente el parametro de HFN. La PDU de Reseteo puede a continuacion modificarse de modo que el terminal de usuario incrementa su valor de HFN tras la recepcion. Esto puede conseguirse, por ejemplo, transmitiendo la PDU de Reseteo con un numero de secuencia de transmision inicial o fuera de secuencia.
Como resultado de las etapas anteriores, los parametros de HFN y numeros de secuencia de transmision del RNC objetivo y del terminal de usuario se sincronizaran. Para conseguir esta sincronizacion, es preferible pero no necesario proporcionar un nuevo activador para el procedimiento de Reseteo de RLC. Mas espedficamente, bajo condiciones de operacion normales se realiza un procedimiento de Reseteo de RLC cuando se detecta un error de protocolo de RLC y/o cuando se detecta una de tres condiciones de activacion especificadas en la especificacion del 3GPP. En esta realizacion de la presente invencion, el procedimiento de Reseteo puede realizarse cuando se detecta una cuarta condicion de activacion. Haciendo referencia a la especificacion, se realiza el procedimiento de reseteo de RLC, si se detecta uno de los siguientes activadores.
1) “No_Descarte despues de MaxDAT numero de retransmisiones” esta configurado y VT(DAT) es igual al valor de MaxDAT;
2) VT(MRW) es igual al valor de MaxMRW;
3) Se recibe una PDU de ESTADO que incluye “Numero de Secuencia erroneo”;
Mas espedficamente, de acuerdo con una realizacion alternativa de la presente invencion, una nueva C-primitiva (un mensaje de control desde el RRC al RLC) y un nuevo activador en el protocolo RLC se usan para iniciar el procedimiento de Reseteo.
Durante el procedimiento de Reseteo, puede realizarse al menos una etapa adicional. En esta etapa, todas las SDU de RLC en el terminal de usuario y el RNC objetivo se vadan. Aunque esta realizacion de la invencion requiere algun tiempo para realizar y puede sufrir de alguna perdida de datos, proporciona una solucion evidente al problema de contrasenas de cifrado no sincronizadas realizadas mediante el sistema de la tecnica relacionada.
B.2. RNC de origen transfiere VT(S) a RNC objetivo.
Haciendo referencia de nuevo a la Figura 11, esta realizacion de la invencion es similar a la realizacion analizada en A.2 anteriormente, excepto que se tiene en cuenta un enfoque diferente para la ventana de recepcion en el terminal de usuario y el hecho de que las PDU de RLC se re-transmiten en el modo operacional de AM.
Por consiguiente, en vez de ajustar el numero de secuencia de la PDU de RLC a transmitir al terminal y sincronizar el valor de HFN, puede requerirse al RNC objetivo considerar unidades de datos previamente transmitidas al terminal mediante el RNC de origen que no se confirmaron por el terminal de usuario. Las siguientes etapas pueden tomarse para compensar este eventual problema.
En la etapa de procedimiento B.2.1., el RNC de origen transfiere un mensaje 90 que contiene informacion relacionada con el ajuste de la SRB2 al RNC objetivo. Esta informacion incluye el numero de secuencia, variable de estado VT(S), y el parametro de HFN usado por la capa de RLC del RNC de origen, junto con una o mas PDU de RLC o un mensaje de RRC que se esta re-transmitiendo. En la etapa de procedimiento B.2.2., el RNC objetivo a continuacion transmite una o mas PDU 100 a re-transmitirse al terminal de usuario usando la informacion transferida desde el RNC de origen. Como resultado, el RNC objetivo transmitira las PDU de la misma manera y con la misma informacion que el RNC de origen.
Como un ejemplo, considerese el caso donde el RNC de origen transmite su parametro de HFN, una o mas PDU de RLC a re-transmitirse, VT(S) que indica numero de secuencia, y VT(A) en la etapa B1 de la Figura 11. El RNC objetivo almacena las PDU desde el RNC de origen despues de que configura la capa de RLC con los parametros recibidos (Etapa B.2.2 en la Figura 11), y envfa un Mensaje de Informacion de Movilidad de UTRAN con una nueva PDU que inicia con el numero de secuencia que corresponde a VT(S). Puesto que el RNC objetivo puede transmitir datos mientras mantiene un estado de memoria intermedia de re-transmision de la SRB2 igual al estado de memoria intermedia de re-transmision del RNC de origen, el terminal de usuario puede recuperar los datos re-transmitidos desde el RNC objetivo a traves del canal de SRB2.
5
10
15
20
25
30
35
40
45
50
55
De acuerdo con otra realizacion, el RNC de origen entrega VT(S) al RNC objetivo a traves de un contenedor de informacion de RRC. El RNC objetivo a continuacion establece SRB2 (RLC de AM) con los valores transferidos y envfa un mensaje de RRC al terminal de usuario con estos valores. El terminal de usuario opera de una manera diferente en comparacion con A.2. puesto que el RLC de AM del terminal recibe las PDU que unicamente radican en un intervalo valido de una ventana de recepcion.
Si el numero de secuencia de transmision que corresponde a la variable VT(S) es igual a VR(R), no tienen lugar problemas. Pero si VT(S) es mayor que VR(R) (principalmente debido a las SDU no confirmadas de RLC en el RLC de origen), el terminal de usuario transmitira una PDU de estado al RNC objetivo que indica que las PDU de AMD desde VR(R) a VT(S)-1 se han perdido. Si no se toma accion apropiada, puede tener lugar el siguiente problema: puesto que VT(A) = VT(S), el RLC objetivo encuentra que las PDU de estado recibidas contienen un “Numero de Secuencia erroneo” e iniciaran un procedimiento de Reseteo. Las PDU de RLC transmitidas antes de que el procedimiento de Reseteo se implemente se perderan (observese que las memorias intermedias de RLC pueden vaciarse durante el procedimiento de Reseteo).
Para garantizar la transmision satisfactoria, esta realizacion de la presente invencion entrega VT(A) ademas de VT(S) desde el RNC de origen al RNC objetivo. El RNC objetivo a continuacion transmite las pDu en SRB2 basandose en VT(A), VT(S) y el parametro de HFN transferido desde el RNC de origen. Puede a continuacion realizarse un procedimiento de establecer y modificar como se ha analizado en relacion con la realizacion A.2. de la invencion.
El mensaje de RRC se transmite mediante las PDU de AMD desde VT(S). Si se transmite una PDU de estado que indica que el terminal de usuario no recibio las PDU desde VR(R) a VT(S)-1 desde el terminal al RNC objetivo, el RNC objetivo transmite un mensaje MRW SUFI al terminal de usuario para mover la ventana de receptor a VT(S). Para implementar estas caractensticas, puede usarse un activador adicional para transmitir el mensaje MRW SUFI. En consecuencia, puede implementarse una nueva C-primitiva junto con un nuevo activador para realizar un descarte de SDU con el procedimiento de senalizacion explfcito.
De acuerdo con una realizacion alternativa, el RNC de origen entrega su valor de HFN y VT(S) al RNC objetivo (Etapa B.2.1. en la Figura 11), y deja de transmitir PDU al terminal de usuario antes de la reubicacion de SRNS. En el RLC del terminal, se completa el procesamiento de mensajes de RRC anteriores. Por lo tanto, la primera PDU recibida despues de la reubicacion de SRNS incluye el mensaje de Informacion de Movilidad de UTRAN que tiene el valor VT(S).
De acuerdo con otra realizacion, el RNC de origen entrega su valor de HFN y VT(S) al RNC objetivo (procedimiento B.2.1. en la Figura 11). El RNC de origen a continuacion transmite un comando al terminal de usuario para ordenar a la capa de RLC del terminal de usuario mover su ventana de recepcion y no solicitar re-transmision de datos. La capa de RRC de la UTRAN puede usarse para ordenar a la capa de RLC del RNC de origen transmitir este comando. Las etapas restantes del procedimiento son similares a la realizacion analizada inmediatamente anterior, sin embargo esta realizacion puede implementarse para eliminar mensajes de RRC antes de que se reubique el SRNS y para resolver el problema de retransmision.
En una o mas de las realizaciones B.2. anteriormente analizadas, puede realizarse una etapa opcional de incluir un indicador de inicio de datos en la primera PDU transmitida por el rNc objetivo al terminal de usuario. El indicador de inicio de datos puede ser el mismo tipo transmitido en el mensaje de RRC transmitido desde el RNC objetivo a traves de SRB1 de acuerdo con la realizacion previamente analizada.
Se aplica el siguiente ejemplo: la PDU de RLC que corresponde al numero de secuencia de VT(S)-1 puede no haberse recibido correctamente. La siguiente PDU de RLC transmitida por el RNC objetivo justo despues de que se realiza el procedimiento de reubicacion puede incluir el indicador de inicio de datos.
B.3. No enviar informacion de movilidad de UTRAN en SRB2 en caso de reubicacion de SRNS. A partir de las realizaciones B.1. y B.2., es evidente que la transmision de un mensaje de RRC en SRB2 puede ser problematica en algunos aspectos. En esta realizacion B.3, puede implementarse la realizacion A.1 o A.2 sin la transmision de Informacion de Movilidad de UTRAN en SRB2.
Las realizaciones analizadas anteriormente se realizan todas preferentemente antes o durante la transmision de Informacion de Movilidad de UTRAN (Caso I) o un mensaje de Confirmacion de Actualizacion de Celula/URA (Caso II). Es decir, cualquier tipo de mensaje que pueda recibirse mediante el terminal de usuario cuando se realizan las realizaciones A y B de la invencion. Incluso aunque el terminal de usuario pueda recibir mensajes de RRC de enlace descendente correctamente desde la UTRAN, pueden surgir ciertas situaciones que evitaran que el RNC objetivo reciba un mensaje de Confirmacion de Informacion de Movilidad de UTRAN desde el terminal de usuario en ambos Casos I y II. Este mensaje de confirmacion puede enviarse en SRB2 (AM/DCCH), pero puesto que VT(S) en el terminal de usuario y VR(R) en el RNC objetivo son normalmente diferentes (por ejemplo, VT(S) t 0, VR(R) = 0) puede surgir una necesidad de sincronizar los valores de HFN y SN en el terminal de usuario y RNC objetivo antes de que se transmita el mensaje de Confirmacion de Informacion de Movilidad de UTRAN. Las siguientes realizaciones de la presente invencion tratan este problema
5
10
15
20
25
30
35
40
45
50
55
C.1. Terminal de usuario recibe mensaje de RRC de enlace descendente en SRB1 (UM/CCCH). Haciendo referencia a la Figura 12, en este caso unicamente el HFN de enlace descendente de SRB1 esta sincronizado. Antes de la transmision de un mensaje de RRC de enlace ascendente (es decir, un mensaje de RRC desde el terminal al RNC objetivo), tanto el RNC objetivo como el terminal de usuario debenan realizar las operaciones 110 y 120 que establecen y re-establecen respectivamente SRB2. Esto incluye ajustar tanto el RNC objetivo como terminal de usuario al mismo valor de HFN. Estas etapas pueden conseguirse cifrando un mensaje transmitido desde el terminal de usuario al RNC objetivo con un valor de HFN incrementado (por ejemplo, el valor actual de HFN + 1) como se realiza en el caso de un Traspaso Definitivo y reubicacion de SRNS combinados. Otro valor posible para HFN es MAX(HFN de UL de SRB2 | HfN de DL de SRB2) + 1. Puede usarse cualquier valor siempre que el terminal de usuario y el RNC objetivo tengan el mismo HFN.
C.2. Terminal de usuario recibe mensaje de RRC de enlace descendente en SRB2 (AM/DCCH) con un procedimiento de RESETEO. Si el terminal de usuario recibe un mensaje de RRC de enlace descendente en SRB2 y se realiza la realizacion de B.1, SRB2 no tiene que establecerse/re-establecerse despues de que se reciba el mensaje. Durante el procedimiento de Reseteo, los valores de HFN en el terminal de usuario y del RNC objetivo (HFN de UL y de DL) estan sincronizados y el terminal de usuario envfa un mensaje de RRC de UL al RRC objetivo sin re-establecer SRB2. Despues de la transmision del mensaje de RRC de UL, tanto el terminal de usuario como la UTRAN debenan establecer/re-establecer las SRB (excepto SRB2) y las RB con el valor de INICIO incluido en el mensaje de Confirmacion de Informacion de Movilidad de UTRAN.
C.3. Terminal de usuario recibe mensaje de RRC de enlace descendente en SRB2 (AM/DCCH) con un descarte de SDU con procedimiento de senalizacion explicito. Si el terminal de usuario recibe un mensaje de RRC de DL en SRB2 y se realiza la realizacion de B.2., unicamente esta sincronizado el HFN de DL de SRB2. Puesto que el HFN de UL no esta sincronizado, SRB2 debe establecerse/re-establecerse tanto en el terminal de usuario como en la UTRAN. El resto del procedimiento es el mismo que en C.1. excepto que SRB1 de DL necesita re-restablecerse.
En una o mas de las realizaciones C analizadas anteriormente, despues de la transmision del mensaje de RRC de UL, tanto el terminal de usuario como la UTRAN pueden re-establecer/establecer las SRB (excepto sRB2) y las RB con un valor de INICIO que corresponde a un valor inicial del HFN. Esto puede conseguirse transmitiendo el valor de INICIO en el mensaje de RRC, es decir, el mensaje de Confirmacion de Informacion de Movilidad de UTRAN. Como un ejemplo, el valor de INICIO puede almacenarse en los 20 bits superiores del HFN. Si el tamano del HFN supera 20 bits, los bits restantes pueden inicializarse a 0. El valor de INICIO puede corresponder a un valor predeterminado (que puede definirse, por ejemplo, de acuerdo con las normas desarrolladas por el 3GPP) y puede gestionarse mediante un modulo de cifrado del terminal. El valor de INICIO puede desconectarse del terminal o puede actualizarse de acuerdo con un cambio en el valor de HFN durante la conexion.
Debena indicarse que la realizacion de C.1. puede aplicarse para todos los casos. Aunque el terminal de usuario reciba un mensaje de RRC de DL en SRB2 con un Procedimiento de Reseteo en C.2, el re-establecimiento de SRB2 no crea problemas en operacion normal. En este caso, los HFN pueden actualizarse un maximo de dos veces.
En las realizaciones anteriores, puede preferirse no incluir un IE (elemento de informacion) “indicador de re- establecimiento de RLC (RB2, RB3, y RB4)” en el mensaje de Confirmacion de Actualizacion de Celula. Si se incluye, el terminal de usuario puede re-establecer SRB2, SRB3, y SRB4 y establecer sus valores de HFN a un valor de INICIO incluido en el ultimo mensaje de Actualizacion de Celula transmitido. Puesto que el terminal de usuario SRB2 se re-establece con este valor de INICIO, la UTRAN puede no ser capaz de recibir un mensaje de Confirmacion de Informacion de Movilidad de UTRAN (SRB2 de UTRAN se establece con cualquiera de HFN+1 o MAX(HFN de UL de SRB2 | HFN de DL de SRB2) + 1). Se indica adicionalmente que estas realizaciones pueden corresponder a todas las SRB y RB comunes. Sin embargo, para SRB2, puesto que el valor de HFN esta sincronizado antes de que se transmita el mensaje de Confirmacion de Informacion de Movilidad de UTRAN, puede no ser necesario resetear el valor de HFN. Tambien, aunque el valor inicial para VT(US) se ha analizado ilustrativamente como que corresponde a cero, los expertos en la materia pueden apreciar que pueden usarse otros valores iniciales para esta o cualquier otra variable de estado analizada en el presente documento.
Las realizaciones de la presente invencion se han adoptado en las siguientes especificaciones tecnicas del 3GPP que se incorporan por referencia en el presente documento: especificacion tecnica TS 25.303 v3.10.0, especificacion tecnica TS 25.303 v3.11.0, especificacion tecnica TS 25.322 v3.9.0, especificacion tecnica TS 25.331 v3.9.0, especificacion tecnica TS 25.331 v3.10.0, y todas las actualizaciones, revisiones y modificaciones a las mismas.
Puede proporcionarse un re-establecimiento de diversas realizaciones de la invencion como se ha indicado anteriormente como sigue.
Actualizacion de celula/URA y reubicacion de SRNS combinadas (Portadoras de radio sin perdidas)
El procedimiento de la presente invencion puede iniciarse mediante el RNC de origen que decide realizar una reubicacion de SRNS. Las etapas de este procedimiento, que se han analizado anteriormente y se vuelven a establecer a continuacion, se muestran en mayor detalle en la Figura 13. En este punto, el Caso 1 representa la situacion donde el equipo de usuario (UE) no esta implicado y el Caso 2 representa la situacion en la que el UE esta
5
10
15
20
25
30
35
40
45
50
55
implicado y se realiza una actualizacion de Celula/URA y reubicacion de SRNS combinadas.
En una etapa inicial, se recibe un Comando de Reubicacion de RANAP mediante el RNC de origen desde la CN, que indica las RAB a liberar y las RAB que se someten a reenvfo de datos. La reubicacion de SRNS sin perdidas puede configurarse para las RAB que se someten a reenvfo de datos. La capa de PDCP soporta numeracion de secuencia de PDCP cuando se soporta reubicacion de SRNS sin perdidas.
Para las portadoras de radio afectadas, la entidad de RLC se detiene y se recuperan los numeros de secuencia de PDCP mediante el RRC. El PDCP envfa y recibe numeros de secuencia que se transfieren a continuacion en el mensaje de Compromiso de Reubicacion de RNSAP desde el RNC de origen al objetivo para las RAB que soportan reubicacion de SRNS sin perdidas. El RNC objetivo se vuelve el RNC servidor cuando se envfa el mensaje de Deteccion de Reubicacion de RANAP.
El RNC objetivo a continuacion envfa un mensaje de INFORMACION DE MOVILIDAD DE UTRAN (Caso 1) en la SRB N.° 1 (UM/DCCH) o SRB N.° 2 (AM/DCCH), o un mensaje de CONFIRMACION DE ACTUALIZACION DE CELULA/URA (Caso 2) en la SRB N.° 1 (UM/DCCH), que configura el UE con la nueva U-RNTI e indica el numero de secuencia de PDCP de recepcion de enlace ascendente para cada portadora de radio configurada para soportar reubicacion de SRNS sin perdidas.
Si se ha de usar la SRB N.° 1, el RNC objetivo establece la entidad de RLC de UM para la SRB N.° 1 y los valores de HUN de DL y/o VT(US) se establecen a los valores en el contenedor de RRC. Al realizar esta etapa, el valor de HFN de DL puede establecerse al valor de HFN de DL actual incrementado en uno. En la entidad de RLC de UM, se usa preferentemente un “LI Especial” para indicar que una SDU de RLC empieza en el comienzo de una PDU de RLC.
Si se ha de usar la SRB N.° 2, el RNC objetivo establece la entidad de RLC de AM y los valores de HFN de DL y de UL se establecen a los valores de HFN de DL y de UL actuales. Antes de enviar un mensaje de INFORMACION DE MOVILIDAD DE UTRAN, el lado de transmision de la entidad de RLC de AM inicia el procedimiento de RESETEO de RLC para sincronizar los valores de HFN entre la UTRAN y el UE.
Tras la recepcion mediante el UE del mensaje, el UE compara el numero de secuencia de PDCP de recepcion de enlace ascendente con el numero de secuencia de PDCP de envfo de enlace ascendente de UE. Si esto confirma que las SDU de PDCP se transfirieron satisfactoriamente antes del inicio de la reubicacion (es decir, ya recibidas mediante el RNC de origen), entonces estas se descartan mediante el UE, el UE re-inicializa las entidades de compresion de encabezamientos de PDCP de las portadoras de radio configuradas para usar un protocolo de compresion de encabezamientos. La entidad de RLC (por ejemplo, RLC de AM) para la SRB N.° 2 se (re-)establece tanto en los lados de UTRAN como de UE, y sus valores de HFN se establecen a VALOR incrementado en uno. (En este punto, VALOR puede definirse como cualquiera del valor de HFN actual o MAX (HFN de UL de SRB2 | HFN de UL de SRB12)).
Si el UE se ha configurado satisfactoriamente a sf mismo, debera enviar un mensaje de CONFIRMACION DE INFORMACION DE MOVILIDAD DE UTRAN (Caso 1 y Caso 2). Estos mensajes contienen preferentemente los valores de INICIO y el numero de secuencia de PDCP de recepcion de enlace descendente para cada portadora de radio configurada para soportar reubicacion de SRNS sin perdidas.
Tras la recepcion y acuse de recibo mediante la UTRAN del mensaje, la UTRAN compara el numero de secuencia de PDCP de recepcion de enlace descendente con el numero de secuencia de PDCP de envfo de enlace descendente. La UTRAN inicializa las entidades de compresion de encabezamientos de PDCP de las portadoras de radio configuradas para usar un protocolo de compresion de encabezamientos. Las entidades de RLC para las portadoras de radio afectadas (distintas de la SRB N.° 2) se (re-)establecen tanto en el lado de la UTRAN como de UE. Los valores de HFN para cada RB se establecen preferentemente al valor de INICIO en el mensaje para el dominio de CN correspondiente, y todas las memorias intermedias de datos se vacfan.
En caso de fallo, el UE debera enviar un mensaje de FALLO DE INFORMACION DE MOVILIDAD DE UTRAN (Caso 1 y Caso 2).
Tras la recepcion del FALLO/CONFIRMACION DE INFORMACION DE MOVILIDAD DE UTRAN (Caso 1 y Caso 2), el procedimiento de reubicacion finaliza.
Actualizacion de celula/URA y reubicacion de SRNS combinadas (Portadoras de radio sin interrupciones)
El procedimiento de la presente invencion puede iniciarse mediante el RNC de origen que decide realizar una reubicacion de SRNS. Las etapas de este procedimiento, que se han analizado anteriormente y se vuelven a establecer a continuacion, se muestran en mayor detalle en la Figura 14. En este punto, el Caso 1 representa la situacion donde el equipo de usuario (UE) no esta implicado y el Caso 2 representa la situacion en la que el UE esta implicado y se realiza un actualizacion de Celula/URA y reubicacion de SRNs combinadas.
5
10
15
20
25
30
35
40
45
50
En una etapa inicial, se recibe un Comando de Reubicacion de RANAP mediante el RNC de origen desde la CN, que indica las RAB a liberar. El RNC de origen continua la transmision de datos de enlace descendente en las portadoras de radio que soportan reubicacion de SRNS sin interrupciones hasta que el RNC objetivo se hace el RNC servidor. El RNC objetivo se hace el RNC servidor cuando se envfa el mensaje de Deteccion de Reubicacion de RANAP.
El RNC objetivo envfa un mensaje de INFORMACION DE MOVILIDAD DE UTRAN (Caso 1) en la SRB N.° 1 (UM/DCCH) o SRB N.° 2 (AM/DCCH), o un mensaje de CONFIRMACION DE ACTUALIZACION DE CELULA/URA (caso 2) en la SRB N.° 1 (Um/DCCH), que configura el UE con la nueva U-RNTI.
Si se ha de usar la SRB N.° 1, el RNC objetivo establece la entidad de RLC de UM y el valor de HFN de DL se establece al valor de HFN de DL actual incrementado en uno. En la entidad de RLC de UM, se usa preferentemente un “LI Especial” para indicar que una SDU de RLC empieza en el comienzo de una PDU de RLC.
Si se ha de usar la SRB N.° 2, el RNC objetivo establece la entidad de RLC de AM y los valores de HFN de DL y de UL se establecen a los valores de HFN de DL y de UL actuales. Antes de enviar un mensaje de INFORMACION DE MOVILIDAD DE UTRAN, el lado de transmision de la entidad de RLC de AM inicia el procedimiento de RESETEO de RLC para sincronizar los valores de HFN entre la UTRAN y el UE.
Tras la recepcion mediante el UE del mensaje, la entidad de RLC para la SRB N.° 2 se (re-)establece tanto en los lados de UTRAN y del UE, y sus valores de HFN se establecen a VALOR incrementado en uno. (En este punto, VALOR puede definirse como cualquiera del valor de HFN actual o MAX (HFN de UL de SRB2 | HFN de DL de SRB2)).
Si el UE se ha configurado satisfactoriamente a sf mismo, debera enviar un mensaje de CONFIRMACION DE INFORMACION DE MOVILIDAD DE UTRAN (Caso 1 y Caso 2). Este mensaje contiene preferentemente los valores de INICIO (a usarse en proteccion de integridad y en cifrado en las portadoras de radio que usan RLC de UM y de AM).
Tras la recepcion y acuse de recibo mediante la UTRAN del mensaje, la UTRAN inicializa y el UE re-inicializa las entidades de compresion de encabezamientos de PDCP de las portadoras de radio configuradas para usar un protocolo de compresion de encabezamientos. Las entidades de RLC para las portadoras de radio afectadas (distintas de la SRB N.° 2) se (re-)establecen tanto en el lado de la UTRAN como de UE. Los valores de HFN para cada RB se establecen preferentemente al valor de INICIO en el mensaje para el correspondiente dominio de Cn y todas las memorias intermedias de datos se vacfan. En caso de fallo, el Ue debera enviar un mensaje de FALLO dE INFORMACION DE MOVILIDAD DE UTRAN (Caso 1 y Caso 2). Tras la recepcion del mensaje de FALLO/CONFIRMACION DE INFORMACION DE MOVILIDAD DE UTRAN (Caso 1 y Caso 2), el procedimiento de reubicacion finaliza.
En las realizaciones anteriores, para iniciar el procedimiento la UTRAN puede transmitir un mensaje de INFORMACION DE MOVILIDAD DE UTRAN al UE en el DCCH de enlace descendente usando el RLC de AM o de UM. En el caso de la reubicacion de SRNS, el mensaje puede enviarse usando RLC de UM unicamente.
Portadoras de radio de senalizacion/celula de procedimientos de movilidad de conexion de RRC y procedimientos de actualizacion de URA
Cuando se transmite un mensaje de RRC en DL en DCCH o CCCH o SHCCH usando UM de RLC, el RRC indicara preferentemente al RLC que debena usarse un indicador de longitud de RLC especial. El UE puede suponer que esta indicacion se ha proporcionado. El indicador de longitud especial indica que una SDU de RLC empieza en el comienzo de una PDU de RLC.
La recepcion de un mensaje de ACTUALIZACION DE CELULA/ACTUALIZACION DE URA mediante la UTRAN basandose en un indicador de longitud especial de este tipo se analizara ahora de acuerdo con una realizacion de la presente invencion. Cuando la UTRAN recibe un mensaje de ACTUALIZACION DE CELULA/ACTUALIZACION DE URA, la UTRAN:
1> en el caso donde el procedimiento se activo mediante la recepcion de una ACTUALIZACION DE CELULA:
2> si se realizo la reubicacion de SRNS:
3> transmitir un mensaje de CONFIRMACION DE ACTUALIZACION DE CELULA en el DCCH de enlace descendente
2> de otra manera:
3> actualizar el valor de INICIO para cada dominio de CN como se mantiene en UTRAN con "INICIO" en el IE "lista de INICIO" para el dominio de CN como se indica mediante la "identidad de dominio de CN" en el IE "lista de INICIO";
5
10
15
20
25
30
35
40
45
3> si este procedimiento se activo mientras el UE no estaba en estado CELULA_DCH, entonces para cada dominio de CN como se indica mediante "identidad de dominio de CN" en el IE "lista de INICIO";
4> establecer los 20 MSB del HFN de MAC-d con el correspondiente valor de INICIO en el IE "lista de INICIO";
4> establecer los restantes LSB del HFN de MAC-d a cero.
3> transmitir un mensaje de CONFIRMACION DE ACTUALIZACION DE CELULA en el DCCH de enlace descendente u opcionalmente en el CCCH pero unicamente si no se requiere cifrado; e
3> incluir opcionalmente el IE "indicador de re-establecimiento de RLC (RB5 y hacia arriba) " para solicitar un re-establecimiento de RLC en el UE, caso en el que las correspondientes entidades de RLC deberian re-establecerse tambien en la UTRAN; o
1> en el caso de que el procedimiento se activo por la recepcion de una ACTUALIZACION DE URA:
2> si se realizo la reubicacion de SRNS:
3> transmitir un mensaje de CONFIRMACION DE ACTUALIZACION URA en el DCCH de enlace descendente
2> de otra manera:
3> transmitir un mensaje de CONFIRMACION DE ACTUALIZACION URA en el CCCH o DCCH de enlace descendente
2> incluir el IE "identidad de URA" en el mensaje de CONFIRMACION DE ACTUALIZACION URA en una celula donde se difunden multiples identificadores de URA, o
1> iniciar un procedimiento de liberacion de conexion de RRC transmitiendo un mensaje de LIBERACION DE CONEXION DE RRC en el CCCH de enlace descendente. En particular, la UTRAN deberia:
2> si el mensaje de ACTUALIZACION DE CELULA se envio debido a un error irrecuperable en RB2, RB3, o RB4:
3> iniciar un procedimiento de liberacion de conexion de RRC transmitiendo un mensaje de LIBERACION DE CONEXION DE RRC en el CCCH de enlace descendente.
Recepcion de mensaje de CONFIRMACION DE ACTUALIZACION DE CELULA/CONFIRMACION DE ACTUALIZACION DE URA mediante el UE
Cuando el UE recibe un mensaje de CONFIRMACION DE ACTUALIZACION DE CELULA/CONFIRMACION DE ACTUALIZACION DE URA; y
- si el mensaje recibido en el CCCH y el IE "U-RNTI" esta presente y tiene el mismo valor que la variable U_RNTI; o
- si el mensaje se recibe en DCCH; el UE puede:
- si el mensaje de CONFIRMACION DE ACTUALIZACION DE CELULA incluye el IE "indicador de re-establecimiento de RLC (RB2, RB3, y RB4)";
- re-establecer las entidades de RLC para la portadora de radio de senalizacion RB2, portadora de radio de senalizacion RB3 y portadora de radio de senalizacion RB4 (si se establece);
- si el valor del IE "Estado" en la variable ESTADO_CIFRADO del dominio de CN almacenado en la variable ULTIMO_DOMINIO_CN_CONFIGURADO se establece a "Iniciado";
- establecer 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 establece) igual al valor de INICIO incluido en el ultimo mensaje de ACTUALIZACION DE CELULA transmitido para el domino de CN almacenado en la variable ULTIMO DOMINIO CN CONFIGURADO;
Las anteriores realizaciones y ventajas son meramente ejemplares y no se han de interpretar como que limitan la presente invencion. La presente ensenanza puede aplicarse facilmente a otros tipos de aparatos. La descripcion de la presente invencion pretende ser ilustrativa, y no limitar el alcance de las reivindicaciones. Seran evidentes muchas alternativas, modificaciones y variaciones para los expertos en la materia. En las reivindicaciones, las clausulas de 5 medios-mas-funcion pretenden cubrir las estructuras descritas en el presente documento como que realizan la funcion indicada y no unicamente equivalentes estructurales sino tambien estructuras equivalentes.

Claims (11)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    REIVINDICACIONES
    1. Un procedimiento de reubicacion de un controlador de red de radio servidor, que comprende:
    recibir, mediante un controlador de red de radio objetivo, una pluralidad de valores de parametros de cifrado desde un controlador de red de radio de origen,
    en el que la pluralidad de valores de parametros de cifrado son para una primera portadora de radio o una segunda portadora de radio,
    en el que al menos uno de la pluralidad de valores de parametros de cifrado es un numero de hiper trama, y en el que uno de la pluralidad de valores de parametros de cifrado es una variable de estado, en lo sucesivo denominado como VT(US), que indica un valor de numero de secuencia que sigue consecutivamente un numero de secuencia de una ultima unidad de datos transmitida desde el controlador de red de radio de origen a un terminal; y
    si la segunda portadora de radio se ha de usar,
    determinar un valor mayor entre un numero de tuper trama de enlace descendente y un numero de tuper trama de enlace ascendente de la segunda portadora de radio; incrementar el valor mayor determinado en uno; y
    usar el numero de tuper trama incrementado como el numero de trama de enlace ascendente y de enlace descendente.
  2. 2. El procedimiento de la reivindicacion 1, en el que la variable de estado es una variable de estado de modo sin acuse de recibo.
  3. 3. El procedimiento de la reivindicacion 1, en el que la primera portadora de radio de senalizacion es SRB N.° 1, y la segunda portadora de radio de senalizacion es SRB N.° 2.
  4. 4. El procedimiento de la reivindicacion 1, que incluye transmitir un primer dato que es un mensaje de control de recurso de radio, que es uno de mensaje de iNfORMACION DE MOVILIDAD DE UTRAN y mensaje de CONFIRMACION DE ACTUALIZACION DE CELULA/URA, al terminal mediante el controlador de red de radio objetivo.
  5. 5. El procedimiento de la reivindicacion 1, en el que un primer dato se cifra usando el valor de parametro de cifrado de enlace descendente para la primera portadora de radio y un primer numero de secuencia.
  6. 6. El procedimiento de la reivindicacion 1, que comprende adicionalmente transmitir un primer dato cifrado al terminal mediante el controlador de red de radio objetivo.
  7. 7. El procedimiento de la reivindicacion 1, que comprende adicionalmente:
    cifrar un segundo dato usando un valor de parametro de cifrado incrementado y un segundo numero de secuencia mediante el terminal, en el que el segundo dato incluye un valor de inicio del valor de parametro de cifrado incrementado;
    transmitir el segundo dato cifrado desde el terminal al controlador de red de radio objetivo; y
    descifrar el segundo dato cifrado mediante el controlador de red de radio objetivo usando el valor de parametro
    de cifrado incrementado.
  8. 8. El procedimiento de la reivindicacion 7, que comprende adicionalmente:
    modificar otros valores de parametros de cifrado basandose en el valor de inicio tanto en el terminal como en el
    controlador de red de radio objetivo para otras portadoras de radio; y
    transmitir y recibir datos entre el terminal y el controlador de red de radio objetivo.
  9. 9. Un procedimiento para procesar datos durante la reubicacion de sub-sistema de red de radio servidor, en lo sucesivo denominado como SRNS, el procedimiento realizado mediante un terminal movil, comprendiendo el procedimiento:
    determinar un valor mayor entre un numero de tuper trama de enlace descendente y un numero de tuper trama de enlace ascendente de una segunda portadora de radio; incrementar el valor mayor determinado en uno; y
    cifrar un segundo mensaje usando el valor mayor determinado incrementado en uno.
  10. 10. El procedimiento de la reivindicacion 9, en el que la primera portadora de radio es SRB1, y la segunda portadora de radio es SRB2.
  11. 11. Un terminal movil adaptado para procesar datos durante la reubicacion de sub-sistema de red de radio servidor, en lo sucesivo denominado como SRNS, comprendiendo el terminal movil:
    una unidad de controlador adaptada para realizar las etapas de:
    determinar un valor mayor entre un numero de hiper trama de enlace descendente y un numero de huper trama de enlace ascendente de una segunda portadora de radio; incrementar el valor mayor determinado en uno; y
    cifrar un segundo mensaje usando el valor mayor determinado incrementado en uno.
ES07021120.6T 2002-02-16 2003-02-14 Procedimiento de reubicación de SRNS en un sistema de comunicación móvil Expired - Lifetime ES2578260T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR20020008341A KR100765123B1 (ko) 2002-02-16 2002-02-16 Ｓｒｎｓ 재할당 방법
KR20020008341 2002-02-16

Publications (1)

Publication Number Publication Date
ES2578260T3 true ES2578260T3 (es) 2016-07-22

Family

ID=19719277

Family Applications (2)

Application Number Title Priority Date Filing Date
ES07021120.6T Expired - Lifetime ES2578260T3 (es) 2002-02-16 2003-02-14 Procedimiento de reubicación de SRNS en un sistema de comunicación móvil
ES03003405T Expired - Lifetime ES2373710T3 (es) 2002-02-16 2003-02-14 Procedimiento de reubicación de srns y controlador de red radio correspondiente.

Family Applications After (1)

Application Number Title Priority Date Filing Date
ES03003405T Expired - Lifetime ES2373710T3 (es) 2002-02-16 2003-02-14 Procedimiento de reubicación de srns y controlador de red radio correspondiente.

Country Status (15)

Country Link
US (3) US7356146B2 (es)
EP (2) EP1337125B1 (es)
JP (2) JP4269161B2 (es)
KR (1) KR100765123B1 (es)
CN (1) CN1633762B (es)
AT (1) ATE532358T1 (es)
AU (1) AU2003207130B2 (es)
ES (2) ES2578260T3 (es)
GB (1) GB2387510B (es)
HK (1) HK1058590A1 (es)
MX (1) MXPA04007854A (es)
RU (1) RU2287228C2 (es)
UA (1) UA77049C2 (es)
WO (1) WO2003069806A1 (es)
ZA (1) ZA200405611B (es)

Families Citing this family (157)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10050117A1 (de) * 2000-10-11 2002-04-25 Philips Corp Intellectual Pty Drahtloses Netzwerk mit einem Datenaustausch nach der ARQ-Methode
CN100551138C (zh) * 2002-08-16 2009-10-14 北京三星通信技术研究有限公司 由drnc发起为mbms建立与核心网的数据连接的方法
US6765888B2 (en) * 2002-08-23 2004-07-20 Motorola, Inc. Control PDU for early target paging for packet data modes
US20040085923A1 (en) * 2002-11-01 2004-05-06 Motorola, Inc. Method and apparatus for cell reselection within a communications system
KR20040040724A (ko) * 2002-11-07 2004-05-13 엘지전자 주식회사 무선 이동 통신 시스템의 상향 공통채널 및 그 운용 방법
KR100548322B1 (ko) * 2003-02-04 2006-02-02 엘지전자 주식회사 무선 통신 시스템의 오류 방지 알엘씨 재설정 방법
WO2004075582A1 (en) 2003-02-21 2004-09-02 Nortel Networks Limited Data communication apparatus and method for establishing a codec-bypass connection
MXPA03010315A (es) * 2003-11-11 2005-05-13 Stack Ltd Metodo y aparato para establecer una aplicacion en tiempo para la proteccion de la integridad de un enlace ascendente a traves de la senalizacion de la portadora rb0 en un sistema dde telecomunicaciones movil universal.
WO2005053170A2 (en) * 2003-11-24 2005-06-09 Interdigital Technology Corporation Method and apparatus for compiling a protocol data unit
FI20031779A0 (fi) * 2003-12-05 2003-12-05 Nokia Corp Menetelmä, järjestelmä ja lähetettävän puolen yhteyskäytäntöyksikkö datapakettien lähettämiseksi kuittaamattoman toimintamuodon palveluissa
SE0400163D0 (sv) * 2004-01-28 2004-01-28 Ericsson Telefon Ab L M Method and systems of radio communications
US20050185609A1 (en) * 2004-02-16 2005-08-25 Esa Malkamaki Communication method, user terminal, network element and computer program
US8676986B2 (en) * 2004-03-10 2014-03-18 Cisco Technology, Inc. Reduced data session establishment time in CDMA-2000 networks
US8027265B2 (en) 2004-03-19 2011-09-27 Genband Us Llc Providing a capability list of a predefined format in a communications network
US7990865B2 (en) 2004-03-19 2011-08-02 Genband Us Llc Communicating processing capabilities along a communications path
WO2005091668A1 (ja) 2004-03-24 2005-09-29 Nec Corporation 移動体通信システム、基地局及びそれらに用いるｈｓｄｐａ伝送方法
KR101000699B1 (ko) * 2004-04-19 2010-12-10 엘지전자 주식회사 무선링크 제어계층에서의 데이터 처리방법
GB2414361B (en) 2004-05-17 2008-10-01 Ipwireless Inc Arrangement and method for radio network relocation
JP2005333189A (ja) * 2004-05-18 2005-12-02 Yokogawa Electric Corp 通信システム
US7580388B2 (en) 2004-06-01 2009-08-25 Lg Electronics Inc. Method and apparatus for providing enhanced messages on common control channel in wireless communication system
JP4517732B2 (ja) * 2004-06-02 2010-08-04 日本電気株式会社 無線制御装置及びそれを用いた移動通信システム並びにその動作制御方法
US8346157B1 (en) 2004-06-16 2013-01-01 Colby Steven M Content customization in asymmertic communication systems
CN100415033C (zh) * 2004-07-16 2008-08-27 华为技术有限公司 一种服务无线网络子系统重定位的方法
CN100370873C (zh) * 2004-07-19 2008-02-20 华为技术有限公司 解决服务无线网络系统迁移后加解密失败的方法
DE602004023390D1 (de) * 2004-08-16 2009-11-12 Research In Motion Ltd Verfahren zur Verwaltung von Funkkapazität in einem Funkzugriffsnetzwerk
US7596379B2 (en) 2004-08-16 2009-09-29 M-Stack Limited Method for maintaining transparent mode radio bearers in a radio access network
US20060050679A1 (en) * 2004-09-09 2006-03-09 Sam Shiaw-Shiang Jiang Method for On-Line Recovery of Parameter Synchronization for Ciphering Applications
US7463602B2 (en) * 2004-09-13 2008-12-09 Research In Motion Limited Configuring signaling radio bearer information in a user equipment protocol stack
US7830864B2 (en) * 2004-09-18 2010-11-09 Genband Us Llc Apparatus and methods for per-session switching for multiple wireline and wireless data types
US7729346B2 (en) * 2004-09-18 2010-06-01 Genband Inc. UMTS call handling methods and apparatus
US20060062312A1 (en) * 2004-09-22 2006-03-23 Yen-Chi Lee Video demultiplexer and decoder with efficient data recovery
JP5033424B2 (ja) * 2004-09-29 2012-09-26 富士通株式会社 秘匿通信システム
DE102004047692A1 (de) * 2004-09-30 2006-04-13 Siemens Ag Kommunikationssystem und Verfahren zur Bereitstellung eines mobilen Kommunikationsdienstes
GB0422192D0 (en) * 2004-10-06 2004-11-03 Nokia Corp Transfer of a user equipment in a communication system
KR101119096B1 (ko) * 2004-11-04 2012-09-05 엘지전자 주식회사 광대역 무선접속 시스템에서 핸드오버시 적용되는 데이터전송 방법
EP1689130A1 (en) * 2005-02-07 2006-08-09 Lg Electronics Inc. Method for settling an error in a radio link control
KR100670876B1 (ko) * 2005-05-09 2007-01-19 엘지노텔 주식회사 더블유씨디엠에이 시스템에서 에스알엔스 재배치/핸드오버방법
JP4671776B2 (ja) * 2005-06-15 2011-04-20 株式会社エヌ・ティ・ティ・ドコモ 秘匿処理装置及び秘匿処理方法
TW200718238A (en) * 2005-06-16 2007-05-01 Qualcomm Inc Handoffs in a meshed wireless system
US7792150B2 (en) * 2005-08-19 2010-09-07 Genband Us Llc Methods, systems, and computer program products for supporting transcoder-free operation in media gateway
WO2007023364A1 (en) * 2005-08-23 2007-03-01 Nokia Corporation Radio link control unacknowledged mode header optimization
ES2314534T3 (es) * 2005-09-20 2009-03-16 Panasonic Corporation Procedimiento y dispositivo para la señalizacion de segmentacion y concatenacion de paquetes en un sistema de telecomunicaciones.
CN101176356B (zh) * 2005-10-18 2012-06-27 中兴通讯股份有限公司 避免ue测量报告干扰的服务无线网络控制器的重定位方法
WO2007070803A2 (en) * 2005-12-12 2007-06-21 4Homemedia, Inc. System and method for web-based control of remotely located devices using ready on command architecture
EP2262328B1 (en) 2005-12-14 2012-09-26 Research In Motion Limited Method and apparatus for user equipment directed radio resource control
MY149758A (en) 2005-12-22 2013-10-14 Interdigital Tech Corp Method and apparatus for data security and automatic repeat request implementation in wireless communication system
US8635526B2 (en) 2006-05-25 2014-01-21 Qualcomm Incorporated Target advertisement in a broadcast system
US8515336B2 (en) 2006-01-06 2013-08-20 Qualcomm Incorporated Apparatus and methods of selective collection and selective presentation of content
US8144661B2 (en) * 2006-01-09 2012-03-27 Telefonaktiebolaget L M Ericsson (Publ) Node and a method relating to handover within mobile communication
US7835346B2 (en) 2006-01-17 2010-11-16 Genband Us Llc Methods, systems, and computer program products for providing transcoder free operation (TrFO) and interworking between unlicensed mobile access (UMA) and universal mobile telecommunications system (UMTS) call legs using a media gateway
JP4927877B2 (ja) * 2006-02-10 2012-05-09 クゥアルコム・インコーポレイテッド ユーザー機器仮識別子の秘匿化
US8879500B2 (en) 2006-03-21 2014-11-04 Qualcomm Incorporated Handover procedures in a wireless communications system
US8620328B2 (en) * 2006-03-21 2013-12-31 Qualcomm Incorporated Handover procedures in a wireless communications system
DE602006012448D1 (de) * 2006-04-20 2010-04-08 Alcatel Lucent Verfahren zum Wiedergabeschutz
JP4729000B2 (ja) * 2006-04-27 2011-07-20 イノヴァティヴ ソニック リミテッド 無線通信システムにおいて復号パラメータを同期させる方法及び装置
US8265034B2 (en) * 2006-05-17 2012-09-11 Research In Motion Limited Method and system for a signaling connection release indication
AU2012207044C1 (en) * 2006-05-17 2015-08-13 Blackberry Limited Method and system for signaling release cause indication in a UMTS network
DE602006017517D1 (de) 2006-05-17 2010-11-25 Research In Motion Ltd Verfahren und System zur Anzeige einer Ursache für einen Abbau einer Signalisierungsverbindung in einem UMTS Netz
US7941144B2 (en) * 2006-05-19 2011-05-10 Telefonaktiebolaget Lm Ericsson (Publ) Access control in a mobile communication system
FR2901436B1 (fr) * 2006-05-19 2008-07-04 Airbus France Sas Dispositif de reception de messages, en particulier dans le cadre d'echanges securises de donnees, aeronef et procede associes
TW200803326A (en) * 2006-06-19 2008-01-01 Innovative Sonic Ltd Method and apparatus for data framing in a wireless communications system
CN101128033B (zh) * 2006-08-18 2011-04-20 中兴通讯股份有限公司 重定位中实现加密算法改变的方法
US20080049662A1 (en) * 2006-08-25 2008-02-28 Research In Motion Limited Apparatus, and associated method, for releasing a data-service radio resource allocated to a data-service-capable mobile node
GB0619499D0 (en) * 2006-10-03 2006-11-08 Lucent Technologies Inc Encrypted data in a wireless telecommunications system
KR100938090B1 (ko) * 2006-10-19 2010-01-21 삼성전자주식회사 이동통신 시스템에서 핸드오버 수행 방법 및 장치
US20080101609A1 (en) * 2006-10-31 2008-05-01 Innovative Sonic Limited Method and apparatus for handling protocol error in a wireless communications system
CN101174987A (zh) * 2006-10-31 2008-05-07 华硕电脑股份有限公司 无线通讯系统处理协议错误的方法及其相关装置
ZA200903044B (en) * 2006-11-01 2010-07-28 Ericsson Telefon Ab L M Telecommunication systems and encryption of control messages in such systems
WO2008060097A1 (en) * 2006-11-15 2008-05-22 Samsung Electronics Co., Ltd. Apparatus and method for transmitting/receiving ciphered packet in mobile communication system
KR100953151B1 (ko) * 2006-11-30 2010-04-19 이노베이티브 소닉 리미티드 무선통신시스템에서 연속패킷 연결성을 개선하는 방법 및장치
US20080137687A1 (en) * 2006-12-08 2008-06-12 Innovative Sonic Limited Method and apparatus for handling reordering in a wireless communications system
JP2008148314A (ja) 2006-12-08 2008-06-26 Asustek Computer Inc 無線通信システムにおいてリオーダーを処理する方法及び装置
US20080137574A1 (en) * 2006-12-08 2008-06-12 Innovative Sonic Limited Method and apparatus for handling data delivery in a wireless communications system
CN101622711B (zh) 2006-12-28 2012-07-18 杰恩邦德公司 用于无声插入描述符（sid）转换的方法、系统
US9060316B2 (en) 2007-01-10 2015-06-16 Qualcomm Incorporated Radio resource connection (RCC) establishment for wireless systems
KR100836253B1 (ko) * 2007-01-31 2008-06-10 주식회사 케이티프리텔 Ｗｃｄｍａ 무선망에서의 ｓｒｎｓ 재배치 제어 방법 및장치
WO2008094662A2 (en) 2007-02-01 2008-08-07 Interdigital Technology Corporation Method and apparatus for supporting rlc re-segmentation
US20080226074A1 (en) * 2007-03-15 2008-09-18 Interdigital Technology Corporation Method and apparatus for ciphering packet units in wireless communications
CN101267659B (zh) * 2007-03-16 2012-02-29 中兴通讯股份有限公司 一种服务无线网络子系统重定位的方法
US7978656B2 (en) * 2007-03-26 2011-07-12 Qualcomm Incorporated Sequence numbering for distributed wireless networks
KR101365885B1 (ko) * 2007-04-30 2014-02-24 엘지전자 주식회사 교착상태를 방지하는 데이터 전송 방법
US8358669B2 (en) * 2007-05-01 2013-01-22 Qualcomm Incorporated Ciphering sequence number for an adjacent layer protocol in data packet communications
GB2449629A (en) 2007-05-01 2008-12-03 Nec Corp Buffering numbered unsegmented PDCP SDUs in 3GPP system to assist efficient hard handover
US8331399B2 (en) * 2007-05-07 2012-12-11 Qualcomm Incorporated Re-using sequence number by multiple protocols for wireless communication
US7817595B2 (en) * 2007-05-17 2010-10-19 Htc Corporation Communication system, user device thereof and synchronization method thereof
US8068451B2 (en) * 2007-05-17 2011-11-29 Htc Corporation Communication system, user device thereof and synchronization method thereof
JP5475655B2 (ja) * 2007-06-22 2014-04-16 インターデイジタル テクノロジー コーポレーション ハンドオーバ操作における資源管理のための方法および機器
US8451795B2 (en) * 2007-08-08 2013-05-28 Qualcomm Incorporated Handover in a wireless data packet communication system that avoid user data loss
US8437739B2 (en) 2007-08-20 2013-05-07 Qualcomm Incorporated Method and apparatus for generating a cryptosync
CN101388829B (zh) * 2007-09-10 2011-03-30 大唐移动通信设备有限公司 重定位的信令及数据加密的方法、系统及无线网络控制器
KR100907978B1 (ko) * 2007-09-11 2009-07-15 엘지전자 주식회사 이동통신 시스템에서 ｐｄｃｐ 계층의 상태보고 전송 방법 및 수신장치
CN101389119B (zh) * 2007-09-11 2012-09-05 电信科学技术研究院 Lte系统小区切换过程中数据重传的方法及装置
WO2009035282A2 (en) * 2007-09-13 2009-03-19 Lg Electronics Inc. A method for providing control information using the paging procedure
KR101428816B1 (ko) * 2007-09-28 2014-08-12 엘지전자 주식회사 이동통신 시스템에서의 셀 선택방법 및 단말의 정적상태 검출방법
KR101441138B1 (ko) * 2007-09-28 2014-09-18 엘지전자 주식회사 무선통신 시스템에서 상향링크 시간 동기 수행 방법
US8873471B2 (en) * 2007-10-01 2014-10-28 Qualcomm Incorporated Method and apparatus for implementing LTE RLC header formats
AR068651A1 (es) * 2007-10-01 2009-11-25 Inter Digital Patent Holding I Metodo y aparato para mejorar varias operaciones pdcp y capa 2
EP2195977B1 (en) * 2007-10-02 2015-09-02 Unwired Planet International Limited A method and apparatus for secure handover in a communication network
KR101473010B1 (ko) * 2007-10-17 2014-12-15 엘지전자 주식회사 패킷망을 이용하여 서킷서비스를 제공하는 방법
JP4843660B2 (ja) * 2007-10-22 2011-12-21 イノヴァティヴ ソニック リミテッド 無線通信システムのｐｄｃｐ層においてデータを暗号化する方法及び装置
CN101426244B (zh) * 2007-10-30 2010-12-15 华为技术有限公司 静态迁移中防止用户掉话的方法、系统和装置
US8208498B2 (en) 2007-10-30 2012-06-26 Qualcomm Incorporated Methods and systems for HFN handling at inter-base station handover in mobile communication networks
ATE553628T1 (de) 2007-11-13 2012-04-15 Research In Motion Ltd Verfahren und vorrichtung für status- /modusübergänge
US20090168723A1 (en) * 2007-11-27 2009-07-02 Qualcomm Incorporated Method and apparatus for handling out-of-order packets during handover in a wireless communication system
KR101460359B1 (ko) * 2007-12-13 2014-11-10 삼성전자주식회사 이동통신 시스템에서의 핸드오버 방법 및 장치
KR101532789B1 (ko) * 2008-01-04 2015-07-09 엘지전자 주식회사 재전송 데이터를 처리하는 ｈａｒｑ 동작 방법
US20090175175A1 (en) * 2008-01-04 2009-07-09 Interdigital Patent Holdings, Inc. Radio link control reset using radio resource control signaling
KR101514079B1 (ko) * 2008-01-07 2015-04-21 엘지전자 주식회사 상향링크 시간 동기 타이머의 재구성 방법
GB2457066A (en) * 2008-01-31 2009-08-05 Nec Corp Method of setting up radio bearers in a mobile communications system
EP2290863B1 (en) * 2008-02-04 2014-03-05 LG Electronics Inc. Wireless communication method for transmitting a sequence of data units between a wireless device and a network
US9357233B2 (en) * 2008-02-26 2016-05-31 Qualcomm Incorporated Video decoder error handling
KR101050258B1 (ko) 2008-03-20 2011-07-19 이노베이티브 소닉 리미티드 Ｒｒｃ 연결 프로시저를 향상시키기 위한 방법 및 장치
CN101562834B (zh) * 2008-04-16 2014-04-09 三星电子株式会社 支持宏基站到家用基站切换的方法和系统
US8509180B2 (en) 2008-05-02 2013-08-13 Qualcomm Incorporated Method and apparatus for efficient handover in LTE
KR101550161B1 (ko) 2008-05-30 2015-09-03 인터디지탈 패튼 홀딩스, 인크 비액세스 계층 재송신의 전달 통지를 위한 방법 및 장치
US8898448B2 (en) * 2008-06-19 2014-11-25 Qualcomm Incorporated Hardware acceleration for WWAN technologies
EP2136501B1 (en) * 2008-06-20 2019-12-04 LG Electronics Inc. Method of delivering a PDCP data unit to an upper layer
US8396037B2 (en) * 2008-06-23 2013-03-12 Htc Corporation Method for synchronizing PDCP operations after RRC connection re-establishment in a wireless communication system and related apparatus thereof
US9225481B2 (en) * 2008-08-11 2015-12-29 Qualcomm Incorporated Downlink grants in a multicarrier wireless communication system
US8670376B2 (en) 2008-08-12 2014-03-11 Qualcomm Incorporated Multi-carrier grant design
FI20085924A0 (fi) * 2008-09-30 2008-09-30 Nokia Corp Palvelun tietoyksiköiden uudelleenkokoaminen viestintäjärjestelmässä
AU2009313191B2 (en) * 2008-11-10 2014-03-13 Blackberry Limited Method and apparatus of transition to a battery efficient state or configuration by indicating end of data transmission in long term evolution
US8494451B2 (en) * 2009-01-30 2013-07-23 Nokia Corporation Method, apparatus and computer program product for providing ciphering problem recovery for unacknowledged mode radio bearer
KR101541079B1 (ko) * 2009-02-09 2015-07-31 삼성전자주식회사 이동통신시스템에서 상향 링크 데이터의 암호화처리 장치 및 방법
US8665570B2 (en) 2009-03-13 2014-03-04 Qualcomm Incorporated Diode having a pocket implant blocked and circuits and methods employing same
US8531805B2 (en) 2009-03-13 2013-09-10 Qualcomm Incorporated Gated diode having at least one lightly-doped drain (LDD) implant blocked and circuits and methods employing same
US8228871B2 (en) 2009-03-19 2012-07-24 Telefonaktiebolaget Lm Ericsson (Publ) Wireless handover optimization
US8379547B2 (en) 2009-05-15 2013-02-19 Telefonaktiebolaget L M Ericsson (Publ) Resource selection for transmission of multiple ACK/NACK on PUCCH channel
US9124425B2 (en) * 2009-06-30 2015-09-01 Nokia Technologies Oy Systems, methods, and apparatuses for ciphering error detection and recovery
US8908541B2 (en) 2009-08-04 2014-12-09 Genband Us Llc Methods, systems, and computer readable media for intelligent optimization of digital signal processor (DSP) resource utilization in a media gateway
EP3691347B1 (en) 2009-11-23 2022-02-16 BlackBerry Limited Method and apparatus for state/mode transitioning
CN102763484B (zh) 2009-11-23 2016-06-01 黑莓有限公司 用于状态/模式转换的方法和设备
JP5525621B2 (ja) 2009-11-23 2014-06-18 ブラックベリー リミテッド Ｓｒｉメッセージ伝送に基づいてトリガする状態またはモード遷移
EP2505035A1 (en) * 2009-11-24 2012-10-03 Research In Motion Limited Method and apparatus for state/mode transitioning
US8983532B2 (en) * 2009-12-30 2015-03-17 Blackberry Limited Method and system for a wireless communication device to adopt varied functionalities based on different communication systems by specific protocol messages
KR20140063902A (ko) * 2010-02-10 2014-05-27 블랙베리 리미티드 상태/모드 전이 방법 및 장치
WO2011121298A2 (en) * 2010-03-31 2011-10-06 British Telecommunications Public Limited Company Secure data recorder
CN104967507B (zh) * 2010-06-09 2019-03-08 三星电子株式会社 移动通信系统和移动通信系统中的分组控制方法
US8521160B2 (en) * 2010-08-13 2013-08-27 Blackberry Limited Method and apparatus for handling URA information
KR20120081736A (ko) * 2011-01-12 2012-07-20 삼성전자주식회사 이동 통신시스템에서 알엘씨 엔터티의 재설립 동안의 회복 불능 오류 처리를 위한 방법 및 장치
US8811281B2 (en) 2011-04-01 2014-08-19 Cisco Technology, Inc. Soft retention for call admission control in communication networks
US9204481B2 (en) * 2011-10-07 2015-12-01 Futurewei Technologies, Inc. System and method for transmitting uplink data associated with downlink multiple point transmission
EP2777358B1 (en) 2011-11-11 2018-01-10 BlackBerry Limited Method and apparatus for user equipment state transition
WO2013167339A1 (en) * 2012-05-07 2013-11-14 Nokia Siemens Networks Oy Handling status data units from multiple data streams
WO2013189031A1 (zh) * 2012-06-19 2013-12-27 华为技术有限公司 通信系统、基站、用户设备及信令传输方法
US9282488B1 (en) * 2012-12-21 2016-03-08 Sprint Spectrum L.P. Wireless device network selection
WO2014110786A1 (zh) * 2013-01-18 2014-07-24 华为技术有限公司 数据传输方法及装置
US20150119038A1 (en) * 2013-10-30 2015-04-30 Qualcomm Incorporated Method and apparatus for cell reselection during serving radio network subsystem (srns) relocation
CN104798320B (zh) 2013-11-11 2018-11-09 华为技术有限公司 数据传输方法及装置
US10028311B2 (en) 2014-04-22 2018-07-17 Lg Electronics Inc. Method for processing received PDCP PDUs for D2D communication system and device therefor
JP6052739B2 (ja) * 2014-07-09 2016-12-27 Kddi株式会社 制御装置、基地局、制御方法、及びプログラム
BR112017010340A2 (pt) 2014-11-18 2017-12-26 Ericsson Telefon Ab L M método e aparelho para transmissão eficiente a partir de um estado dormente
US11212700B2 (en) 2017-05-04 2021-12-28 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for detecting delayed or lost control signaling messages
WO2019245179A1 (en) * 2018-06-20 2019-12-26 Lg Electronics Inc. Method for processing a packet located outside of window by reception end in wireless communication system and an apparatus therefor
CN109348491B (zh) * 2018-10-16 2021-11-02 京信网络系统股份有限公司 L2状态变量失步恢复的方法、装置及设备
CN113453380A (zh) * 2020-03-27 2021-09-28 华为技术有限公司 无线局域网中应用于多链路设备的通信方法及装置
CN117812174B (zh) * 2024-02-29 2024-05-10 中国人民解放军国防科技大学 支持流协议报文传输的芯粒互连接口物理链路及接口电路

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
MX9404062A (es) 1993-06-03 1995-01-31 Ericsson Telefon Ab L M Transferencia de llamada dentro del sistema de comunicaciones celulares.
FI972725A (fi) * 1997-06-24 1998-12-25 Nokia Telecommunications Oy Uudelleenreititys
FI105993B (fi) 1997-08-20 2000-10-31 Nokia Mobile Phones Ltd Menetelmä ja järjestelmä radiotiedonsiirtoverkon hallitsemiseksi ja radioverkko-ohjain
FI114768B (fi) * 1999-03-11 2004-12-15 Nokia Corp Parannettu menetelmä ja järjestely tiedon siirtämiseksi pakettiradiopalvelussa
GB2348569B (en) * 1999-03-31 2003-11-05 Ericsson Telefon Ab L M IP Address allocation for mobile terminals
GB2348778A (en) * 1999-04-08 2000-10-11 Ericsson Telefon Ab L M Authentication in mobile internet access
US6466556B1 (en) * 1999-07-23 2002-10-15 Nortel Networks Limited Method of accomplishing handover of packet data flows in a wireless telecommunications system
GB9918636D0 (en) * 1999-08-06 1999-10-13 Nokia Telecommunications Oy Inter-system handover
KR100680072B1 (ko) * 1999-09-14 2007-02-09 유티스타콤코리아 유한회사 비동기 이동통신 시스템에서 호 처리 및 핸드오프 처리 방법
US6782274B1 (en) * 1999-10-21 2004-08-24 Hyundai Electronics Industries Co., Ltd. Method for transmitting radio resource control message in asynchronous mobile communication system
DE60026799T2 (de) * 1999-12-10 2006-10-19 Lucent Technologies Inc. Mobilfunksystem mit synchronisiertem Weiterreichen (Handover)
DE60030404T2 (de) * 2000-02-22 2007-02-22 Lucent Technologies Inc. Vefahren zum Weiterreichen von Echtzeitverbindungen in drahtlosen Kommunikationssystemen
DE10019443A1 (de) * 2000-04-19 2001-10-31 Texas Instruments Deutschland Vorrichtung zum Befestigen eines Halbleiter-Chips auf einem Chip-Träger
FR2809579B1 (fr) * 2000-05-23 2003-07-04 Nortel Matra Cellular Procede de controle d'un canal entre un terminal radio et une infrastructure de radiocommunication cellulaire, et reseau d'acces mettant en oeuvre un tel procede
JP2001339386A (ja) 2000-05-25 2001-12-07 Nec Corp 無線通信システム、無線ネットワーク制御装置、ユーザ端末装置
FI111210B (fi) 2000-08-14 2003-06-13 Nokia Corp Datapakettinumeroiden synkronointi pakettivälitteisessä tiedonsiirrossa
KR100359215B1 (ko) * 2000-12-15 2002-11-04 주식회사 하이닉스반도체 Ｉｍｔ-2000 시스템에서의 핸드오프시 ｓｒｎｃ 재할당 방법
US6862450B2 (en) 2001-02-07 2005-03-01 Nokia Mobile Phones Ltd. Resetting signaling link upon SRNS relocation procedure
US6845095B2 (en) * 2001-04-27 2005-01-18 Telefonaktiebolaget Lm Ericsson (Publ) Efficient header handling involving GSM/EDGE radio access networks
US6725040B2 (en) 2001-07-09 2004-04-20 Asustek Computer Inc. Lossless SRNS relocation procedure in a wireless communications system
KR100595583B1 (ko) 2001-07-09 2006-07-03 엘지전자 주식회사 이동통신시스템에서 핸드오버에 따른 패킷 데이터 전송 방법
KR100423148B1 (ko) * 2001-11-16 2004-03-16 삼성전자주식회사 비동기 ｉｍｔ-2000 통신망 중 패킷망에서의 에스알엔에스재배치 방법 및 에스알엔에스 재배치 시스템
KR100399056B1 (ko) * 2001-11-21 2003-09-26 한국전자통신연구원 무선통신망에서의 가변 서비스품질 파라미터 협상에 의한무선자원 할당 방법
KR100456977B1 (ko) * 2001-11-23 2004-11-10 엘지전자 주식회사 에스지에스엔간 에스알엔에스 재배치 처리 방법
US20030139183A1 (en) 2002-01-11 2003-07-24 Nokia Corporation Method and apparatus for reducing premature termination of mobile station LCS procedure during RR operations
EP1343267A3 (en) 2002-02-08 2005-08-03 ASUSTeK Computer Inc. Data transmission confirmation in a wireless communication system
NO20020667D0 (no) 2002-02-11 2002-02-11 Ericsson Telefon Ab L M Fremgangsmåte for å unngå unödig okkupering av ressurser i pakkesvitsjede mobilnett
US7227857B2 (en) 2002-06-21 2007-06-05 Innovative Sonic Limited Correction to HFN initialization for RB2 during SRNS relocation

Also Published As

Publication number Publication date
GB2387510B (en) 2004-10-13
CN1633762A (zh) 2005-06-29
ATE532358T1 (de) 2011-11-15
CN1633762B (zh) 2013-07-10
EP1337125B1 (en) 2011-11-02
JP2005518135A (ja) 2005-06-16
KR20030068741A (ko) 2003-08-25
HK1058590A1 (en) 2004-05-21
UA77049C2 (en) 2006-10-16
ES2373710T3 (es) 2012-02-08
RU2287228C2 (ru) 2006-11-10
JP2008271583A (ja) 2008-11-06
EP1876855B1 (en) 2016-04-20
US7706537B2 (en) 2010-04-27
ZA200405611B (en) 2005-12-28
GB2387510A (en) 2003-10-15
MXPA04007854A (es) 2004-10-15
WO2003069806A1 (en) 2003-08-21
AU2003207130A1 (en) 2003-09-04
RU2004127673A (ru) 2006-01-27
US20030157927A1 (en) 2003-08-21
JP4269161B2 (ja) 2009-05-27
EP1337125A3 (en) 2006-12-27
KR100765123B1 (ko) 2007-10-11
EP1337125A2 (en) 2003-08-20
US7889867B2 (en) 2011-02-15
US7356146B2 (en) 2008-04-08
EP1876855A2 (en) 2008-01-09
JP4995146B2 (ja) 2012-08-08
EP1876855A3 (en) 2009-11-04
GB0303459D0 (en) 2003-03-19
US20080293416A1 (en) 2008-11-27
AU2003207130B2 (en) 2006-09-07
US20100178923A1 (en) 2010-07-15

Similar Documents

Publication Publication Date Title
ES2578260T3 (es) Procedimiento de reubicación de SRNS en un sistema de comunicación móvil
JP6328196B2 (ja) 移動通信システムにおける無線プロトコル処理方法及び移動通信送信機
JP4652358B2 (ja) パケット交換データ伝送におけるデータ・パケット番号付加方式
JP4303226B2 (ja) 無線通信システムのパケットデータ収斂プロトコル構造（ｐｄｃｐ）およびその方法
EP1928130A2 (en) Apparatuses and methods for performing initialization of the Packet Data Convergence Protocol PDCP in a mobile communication system
US20030236085A1 (en) Method for synchronizing a security start value in a wireless communications network
US7254144B2 (en) Method for synchronizing a start value for security in a wireless communications network
KR101259514B1 (ko) 이기종 이동통신 시스템 간의 무손실 핸드오버 방법 및장치
GB2398974A (en) Method of Relocating SRNS.
KR100856244B1 (ko) 이동통신 시스템에서 자동 재전송 요구 패킷 송수신 장치및 방법
KR20080044148A (ko) 이동통신 시스템에서 암호화된 패킷을 송수신하는 장치 및방법