MXPA04007854A - Metodo para relocalizacion se subsistema de red de radio de servicio. - Google Patents
Metodo para relocalizacion se subsistema de red de radio de servicio.Info
- Publication number
- MXPA04007854A MXPA04007854A MXPA04007854A MXPA04007854A MXPA04007854A MX PA04007854 A MXPA04007854 A MX PA04007854A MX PA04007854 A MXPA04007854 A MX PA04007854A MX PA04007854 A MXPA04007854 A MX PA04007854A MX PA04007854 A MXPA04007854 A MX PA04007854A
- Authority
- MX
- Mexico
- Prior art keywords
- further characterized
- user terminal
- data
- sequence number
- value
- Prior art date
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
Se describe un metodo para realizar relocalizacion de subsistema de red de radio de servicio (SRNS) para un uso efectivo de un recurso de radio en el sistema de telecomunicaciones movil universal del sistema IMT-2000 asincrono, que incluye: determinar una relocalizacion de subsistema de rede de radio de servicio en una red; transmitir un mensaje de control de recurso de radio correspondiente a la relocalizacion de SRNS a la terminal para que el controlador de red se comunique con la terminal; y transmitir un mensaje de control de recurso de radio respuesta correspondiente a la relocalizacion de SRNS al controlador de red de radio al cual es transmitido el mensaje de control de recurso de radio; al hacer eso, se pede realizar la relocalizacion de SRNS exitosa.
Description
METODO PARA RELOCALIZACION DE SUBSISTEMA DE RED DE RADIO DE SERVICIO
La presente invención se refiere a un sistema de comunicación móvil y, muy particularmente, a un método de relocalización de SRNS capaz de cargar SRNC (Controlador de Red de Radio de Servicio) a un uso efectivo de un recurso de radio en un sistema UMTS, un sistema IMT-2000.
TECNICA ANTECEDENTE
Un sistema de telecomunicaciones móvil universal (UMTS) es un sistema de comunicación móvil de tercera generación que ha evolucionado a partir de un estándar conocido como Sistema Global para Comunicación Móvil (GSM). Este estándar es un estándar europeo que tiene la finalidad de proveer un servicio de comunicación móvil mejorado basado en una red de núcleo de GSM y tecnología de acceso múltiple de división de código de banda ancha (W-CDMA). En diciembre de 1998, el ETSI de Europa, la ARIB TTC de Japón, la T1 de los Estados Unidos y la TTA de Corea formaron un Proyecto de Sociedad en Tercera Generación (3GPP) para el propósito de crear la especificación para estandarizar el UMTS. La palabra hacia la estandarización del UMTS realizada por 3GPP ha dado por resultado la formación de cinco grupos de especificación técnica (TSG), cada uno do los cuales está dirigido a formar elementos de red que tienen operaciones independientes. De manera más específica, cada TSG desarrolla, aprueba y maneja una especificación estándar en una región relacionada. Entre ellos, un grupo de red de acceso a radio (RAN) (TSG-RAN) desarrolla una especificación para la función, elementos deseados, y una interfaz de una red de acceso a radio terrestre de UMTS (UTRAN), que es una nueva RAN para soportar una tecnología de acceso a W-CDMA en la UMTS. El grupo TSG-RAN incluye un grupo plenario y cuatro grupos de trabajo. El grupo de trabajo 1 (WG1 ) desarrolla una especificación para una capa física (una primera capa). El grupo de trabajo 2 (WG2) especifica las funciones de una capa de enlace de datos (una segunda capa) y una capa de red (una tercera capa). El grupo de trabajo 3 (WG3) define una especificación para una interfaz entre una estación de base y una UTRAN, un controlador de red de radio (RNC), y una red de núcleo. Finalmente, el grupo de trabajo 4 (WG4) describe requerimientos deseados para la evaluación de un rendimiento de enlace de radio y artículos deseados para manejo de recursos de radio. La figura 1 muestra una estructura de red de un UTMS al cual se puede aplicar una tecnología de técnica de antecedente y la presente invención. El sistema UMTS es empíricamente dividido en un UE (equipo de usuario) (estación móvil), una UTRAN y uná red de núcleo. La UTRAN incluye uno o más subsistemas de red de radio (RNS), y cada RNS incluye un RNC y uno o más nodos Bs manejados por los RNCs. Los nodos Bs son manejados por los RNCs, reciben información enviada por la capa física de una terminal 150 a través de un enlace ascendente, y transmiten datos de una terminal a través de un enlace descendente. Los Nodos Bs, por lo tanto, operan como puntos de acceso de la UTRAN para la terminal. Los RNCs realizan funciones que incluyen la asignación y manejo de recursos de radio. Un RNC que maneja directamente un nodo B se refiere como un RNC de control (CRNC). El CRNC maneja recursos de radio comunes. Un RNC de servicio (SRNC), por otra parte, maneja recursos de radio dedicados asignados a las terminales respectivas. El CRNC puede ser el mismo que el SRNC. Sin embargo, cuando la terminal se desvía de la región del SRNC y se mueve a la región del otro RNC, el CRNC puede ser diferente del SRNC. Los servicios provistos a una terminal específica son clasificados empíricamente a un servicio conmutado en circuito y un servicio conmutado en paquete. Por ejemplo, el servicio de teléfono de voz general pertenece al servicio conmutado en circuito, mientras que un servicio de paginación de Web a través de un acceso de Internet pertenece a un servicio conmutado en paquete. En el caso de soportar el servicio conmutado en circuito, el SRNC es conectado a un MSC (centro de conmutación móvil) de la red de núcleo, y el MSC es conectado a un GMSC (Centro de Conmutación Móvil de Compuerta) para comunicación con una red externa. El GMSC maneja conexión proveniente de otra red o dirigida hacia otra red. En el caso de servicio conmutado en paquete, los servicios son provistos por el SGSN y el GGSN de la red de núcleo. El SGSN (Nodo de Soporte de GPRS de Servicio) soporta un cabezal de comunicación en paquete para el SRNC, mientras que el GGSN (Nodo de Soporte del GPRS de Compuerta) maneja una conexión a una red conmutada en paquete diferente tal como una red de Internet. Existen interfaces entre varios componentes de red para permitir que los componentes de red den y tomen información hacia y desde uno de otro para una comunicación mutua. Una interfaz entre el RNC y la red de núcleo se define como una interfaz lu. La conexión de la interfaz lu del área conmutada en paquete es definida como un lu-PS, mientras que la conexión de la interfaz lu al área conmutada en circuito es definida como un lu-CS. La figura 2 muestra una estructura de un protocolo de interfaz de acceso de radio entre una terminal que opera con base en una especificación de 3GPP RAN y una UTRAN. El protocolo de interfaz de radio se forma horizontalmente de una capa física (PHY), una capa de enlace de datos y una capa de red y está verticalmente dividida en un plano de control para transmitir una información de control y un plano de usuario para transmitir información de datos. El plano de usuario es una región a la cual la información de tráfico de un usuario tal como dos o un paquete IP es transmitida. El plano de control es una región a la cual la información de control tal como una interfaz de una red o mantenimiento y manejo de una llamada es transmitida. En la figura 2, las capas de protocolo se pueden dividir en una primera capa (L1 ), una segunda capa (L2) y una tercera capa (L3) basada en las tres capas inferiores de un modelo estándar de interconexión de sistema abierto (OSI) bien conocido en el sistema de comunicación. La primera capa (L1 ) opera como una capa física (PHY) para una interfaz de radio, y de acuerdo con la tecnología de la técnica antecedente está conectada a una capa de control de acceso al medio superior (MAC) a través de uno o más canales de transporte. La capa física transmite datos suministrados a la capa física (PHY) a través de un canal de transporte a un receptor usando varios métodos de codificación y modulación adecuados para circunstancias de radio. El canal de transporte entre la capa física (PHY) y la capa de MAC se divide en un canal de transporte dedicado y un canal de transporte común basado que si es exclusivamente usado por una sola terminal o compartido por varias terminales. La segunda capa L2 opera como una capa de enlace de datos y deja que varias terminales compartan los recursos de radio en una red W-CDMA. La segunda capa L2 se divide en la capa de MAC, una capa de control de enlace de radio (RLC), una capa de protocolo de convergencia de datos en paquete (PDCP) y una capa de control de difusión/multidifusión (BMC). La capa de MAC suministra datos a través de una relación de mapeo apropiada entre un canal lógico y un canal de transporte. Los canales lógicos que conectan una capa superior y la capa de MAC se dividen en dos tipos de acuerdo con el tipo de información transmitida. Es decir, cuando la información del plano de control es transmitida, se usa un canal de control. Cuando la información del plano de usuario es transmitida, se usa un canal de tráfico. La capa de RLC forma una unidad de datos de protocolo (PDU) de una RLC apropiada, adecuada para la transmisión por las funciones de segmentación y concatenación de una unidad de datos de servicio (SDU) de RLC recibida desde una capa superior. La capa de RLC también realiza una función de requerimiento de repetición automática (ARQ) por medio de la cual una RLC PDU perdida durante la transmisión es retransmitida. La capa de protocolo de convergencia de datos en paquete (PDCP) es una capa superior de la capa de RLC que permite que los elementos de datos sean transmitidos a través de un protocolo de red tal como IPv4 o el IPv6. Una técnica de compresión de encabezamiento para imprimir y transmitir la información de encabezamiento en un paquete se puede usar para transmisión efectiva de paquete IP. Las capas de control de difusión/multidifusión (BMC) permiten que un mensaje sea transmitido de un centro de transmisión de celda (CBC) a través de la interfaz de radio. La función principal de la capa MBC está programando y transmitiendo un mensaje de difusión de celda a una terminal. En general los datos son transmitidos a través de la capa de RLC que opera en el modo no reconocido. La capa de PDCP y la capa de BMC están localizadas únicamente en el plano de usuario debido a que transmiten sólo datos de usuario. A diferencia de la capa de PDCP y la capa de BMC, la capa de RLC se puede incluir en el plano de usuario y el plano de control de acuerdo con una capa conectada a la capa superior. Cuando la capa de RLC pertenece al plano de control, los datos son recibidos desde una capa de control de recurso de radio (RRC). En los otros casos, la capa de RLC pertenece al plano de usuario. La capa de RRC ubicada en la porción más baja entre la tercera capa (L3) está definida sólo en el plano de control y controla los canales lógicos, los canales de transporte y los canales físicos en relación con la preparación, la reconfiguración y la liberación de RBs.
En este tiempo, la preparación de RB significa procedimiento de gesticulación de las características de una placa de protocolo en un canal, que se requieren para proveer un servicio específico, y fijar los parámetros detallados respectivos y los métodos de operación. Es posible transmitir mensajes de control recibidos desde la capa superior a través de un mensaje de RLC. Las operaciones del portador de radio (RB) y la capa de RLC no se describirán ahora con detalle. En general, el servicio de transmisión de datos de usuario provistos desde el plano de usuario a la capa superior por la segunda capa (L2) se refiere como el portador de radio (RB). El servicio de transmisión de información de control provista desde el plano de control a la capa superior por la segunda capa (L2) se refiere como un portador de radio de señalización (SRB). Cada portador de radio es comúnmente transmitido a través de la capa de RLC, de la cual las características de transmisión están determinadas por un modo de operación de la capa de RLC. A saber, de acuerdo con si se realiza una función de segmentación y si se soporta la retransmisión sobre datos recibidos desde la capa superior a la capa de RLC, la capa de RLC opera en los siguientes tres modos: un modo transparente (TM), un modo de no reconocimiento (UM) y un modo de reconocimiento (AM). Primero, cuando la capa de RLC opera en el modo TM, no se agrega información de encabezamiento a la RLC SDU recibida desde la capa superior. No se agrega número de secuencia a la RLC PDU y la retransmisión de datos no es soportada. En general, en el modo TM, la segmentación y reensamble de la RLC SDU no se usa, pero cuando el portador de radio se filtra, ya sea para usar las funciones de segmentación y reensamble se determina de acuerdo con las circunstancias. Segundo, cuando la capa de RLC opera en el modo UM, aún cuando la transmisión de la RLC PDU falla, su retransmisión no es soportada. Por lo tanto, aun cuando los datos se pierden durante la transmisión, un receptor no requiere retransmisión del mismo y los datos relacionados se consideran como una falla. La capa de RLC que opera en la UM construye una RLC PDU segmentando la RLC SDU, y un número de secuencia se agrega a cada RLC PDU a la vez. Por consiguiente, el receptor puede conectar y descifrar los datos sobre la base del número de secuencia. Los servicios que usan el UM RLC incluyen un servicio de difusión de celda y un servicio de voz que usa una red de IP (voz sobre IP) o similar. Mientras tanto, cuando el RLC opera en un modo AM, la retransmisión en paquete es soportada cuando un paquete no es transmitido. En otras palabras, una capa de RLC de un transmisor recibe información de estado sobre si la transmisión ha sido o no exitosa desde un receptor y retransmite una PDU según es necesario. Aunque la RLC opera en el modo AM, la RLC SDU recibida desde la capa superior se divide en tamaños predefinidos por segmentación o concatenación, y como información de encabezamiento que contiene números de secuencia se agrega al mismo para convertir las RLC PDUs, que son almacenadas en una memoria intermedia del RLC sobre la base del número de secuencia. Las RLC PDUs almacenadas son transmitidas a la capa de MAC tantas como sean requeridas por la capa de MAC, y básicamente transmitidas sobre la base del número de secuencia Las primeras RLC PDUs transmitidas son transmitidas con base en el número de secuencia desde la capa de RLC del transmisor, la capa de RLC del receptor observa los números de secuencia recibidos y que quiere la retransmisión de los datos fallados en la transmisión desde la capa de RLC del transmisor. Por ejemplo, si los números de secuencia de las RLC PDUs recibidas son #23, #24, #25, #32 y #34, se puede decir que las RLC PDUs con los números de secuencia de #26-#31 y #33 se han perdido durante la transmisión. La información de estado (PDU de estado) de la memoria intermedia del receptor transmitida al transmisor porta una PDU de estado, por lo que el transmisor puede detectar número de secuencia de RLC PDUs que han de ser retransmitidas y RLC PDUs que han sido exitosamente transmitidas sobre la base del contenido que está contenido en la PDU de estado. La figura 3 muestra una estructura de RLD PDU transmitida desde la capa de RLC.
La RLC PDU consiste de información de encabezamiento y una carga, y la información de encabezamiento contiene información de control diversa. La información de encabezamiento como se muestra en la figura 3 incluye un número de secuencia y un indicador de longitud. El número de secuencia se usa como información de identificación requerida para transmisión consecutiva de datos, mientras que el indicador de longitud indica un límite de la RLC SDU. En el caso del modo UM, el número de secuencia tiene 7 bits, mientras que en el caso del modo AM, la secuencia tiene 12 bits. El campo ?' es un bit de extensión de un bit y se usa para identificar si un campo que ha de ser continuado es el indicador de longitud o datos. El indicador de longitud indica una cara del límite de RLC SDUs en el caso de que varías RLC SDUs sean incluidas en una RLC PDU de acuerdo con la función de concatenación de la capa de RLC. Por lo tanto, sí la RLC SDU no termina en una RLC PDU correspondiente, el indicador de longitud puede no existir. Además, el indicador de longitud también se usa para un propósito especial además de la función de indicar la cara del límite de la RLC SDU. Es decir, un propósito de modelo es una función de indicador de relleno e inicio de datos. El relleno se usa cuando no hay RLC SDU para ser conectado adicionalmente en la RLC PDU correspondiente y la parte de datos de la RLC PDU es mayor que el tamaño de la RLC SDU que ha de ser contenida. Es decir, una porción indicada como relleno significa que son datos insignificantes. En el caso de modo UM, el indicador de inicio de datos se fija como 1 11 1100, mientras que en el caso del modo AM, se fija como 1 11 1 1 11 1 1 1 11100. Con estos valores fijados, la porción de datos que se ha de continuar después del indicador de longitud significa que es la primera porción de una RLC SDU. El indicador de inicio de datos se puede usar para evitar una pérdida de datos adicional en la RLC. Por ejemplo, se supone que una RLC PDU con un número de secuencia 4 se pierde y una RLC PDU con un número de secuencia 5 es recibido. Si una nueva RLC SDU empieza a partir de un número de secuencia 5 y termina dentro del número de secuencia 5, existe un campo de indicador de longitud en la quinta RLC PUD. Sin embargo, si no hay un indicador de inicio de datos, puesto que la cuarta RLC PDU se ha perdido, la capa de RLC del receptor puede suponer que la RLC SDU que pertenece a la quinta RLC PDU se continúa a la RLC SDU en la cuarta RLC PDU y desecha la primera RLC SDU en la quinta RLC PDU. Para transmisión de datos y un manejo efectivo de la memoria intermedia de RLC, la capa de RLC define y usa una variable de estado. La figura 4 muestra una estructura de una memoria intermedia de AM RLC del transmisor y un indicador de estado en la memoria intermedia de RLC. En la AM RLC, las RLC PDUs se almacenan con base en los números de secuencia a su vez, y las RLC PDUs exitosamente transmitidas son suprimidas de la memoria intermedia. Con referencia a la figura 4, la variable de estado de VT(S) indica el número de secuencia de la RLC PDU más pequeña de las PDUs que han de ser transmitidas primero. VT(A) indica el número de secuencia más pequeño entre PDUs esperando un reconocimiento positivo del receptor después de la transmisión. Por lo tanto, el estado de la memoria intermedia indica que el transmisor ha transmitido RLC PDUs hasta la PDU del número de secuencia de VT(S)-1 y ha recibido reconocimiento positivo hasta la RLC PDU de VT(A)-1 del receptor. Aunque la figura 4 muestra el caso de la AM RLC, cuando opera en el modo UM, la capa de RLC usa una variable de estado VT(US) que es similar a VT(S) en el modo AM. Es decir, la VT (US) significa el número de secuencia más pequeño entre las RLC PDUs que han de ser transmitidas primero desde la capa de RLC del transmisor que opera en el modo UM. Sin embargo, puesto que el modo UM no soporta la retransmisión, no es posible recibir confirmación sobre un reconocimiento positivo o un reconocimiento negativo desde el receptor, y por lo tanto la variable de estado tal como VT(A) no está definida. En general, esas variables de estado se fijan como "0" un valor inicial, cuando la capa de RLC se restablece o se vuelve a fijar. Como se mencionó antes, el servicio de transmisión de información de control provisto a la capa superior por la segunda capa (L2) por el plano de control se define como un portador de radio de señalización (SRB). Cada mensaje de RRC es intercambiado entre la terminal y RNC a través de los SRBs, y el establecimiento de un nuevo portador de radio y el restablecimiento y liberación de los portadores de radio previamente fijados se puede instruir. El sistema UMTS puede usar un total de 32 SRBs para la transmisión de información de control entre la terminal y el RNC. Las características de cada SRB se determinan de acuerdo con un modo de operación del RLC que soporta al SRB y el tipo de un canal lógico usado. El canal lógico usado en el SRB incluye un CCCH (Canal de Control Común) y un DCCH (Canal de Control Dedicado) diseñados para transmisión de información de control. CCCH es el canal lógico que porta información de control común entre la terminal y UTRAN, y varias terminales pueden usar el CCCH en forma simultánea. Como el canal lógico común, el CCCH incluye una U-RNTI (Identidad Temporal de Red de Radio UTRAN). Mientras tanto, DCCH es el canal lógico que transmite información de control dedicada entre una terminal específica y UTRAN y es exclusivamente usado por una terminal en vez de ser compartido con otras terminales. Las características de cada tipo de SRB son las siguientes. - SRBO: Para el enlace ascendente se usa TM RLC y para el enlace descendente se usa UM RLC para transmitir mensaje de RRC. El canal lógico usado para el SRBO es CCCH. - SRB1 : se usa UM RLC. SRB1 se usa para transmitir mensajes de RRC a través de DCCH. - SRB2: se usa AM RLC. SRB2 se usa para transmitir mensajes de RRC a través de DCCH y no porta los mensajes de la capa superior. - SRB3: se usa AM RLC. SRB3 porta los mensajes recibidos de la capa superior del RRC a través del DCCH. - SRB4: Este SRB es selectivo. SRB4 también transmite mensajes recibidos de la capa superior de RRC como SRB3 pero se usa para el control de una prioridad con respecto a SRB3. Es decir, SRB4 porta mensajes de prioridad más baja mientras que SRB3 porta mensajes de prioridad más alta. - SRB5-31 : Estos se usan para cada caso en donde los mensajes de RRC son transmitidos usando el DCCH conectado al TM RLC. La figura 5 muestra un procedimiento de reasignación de SRNS típico realizado en el área conmutada en paquete, que también se puede aplicar al área conmutada en circuito. La relocalización de SRNS se usa para establecer la ruta más corta entre la terminal y ia red de núcleo al cambiar el punto de acceso de lu cuando una posición de la terminal cambia a medida que se mueve. Es decir, significa un procedimiento de cambio de SRNC que sirve a una terminal de usuario desde un RNC a otro. Varios elementos de red están implicados con la relocalización de SRNS, por lo que la relocalización de SRNS pasa por un procedimiento muy complicado en comparación con el procedimiento de traspaso general. Con referencia a la figura 5, la terminal está actualmente conectada al RNC1 y el RNC 1 sirve como el SRNC para la terminal correspondiente. El RNC1 está conectado al SGSN1 de la red de núcleo y el SGSN1 está conectado al GGSN para conexión con una red externa. Cuando la terminal se mueve hacia una región que es manejada por el RNC2, se puede considerar que la conexión a SGSN2 a través de RNC2 es más corta que la conexión a SGSN1 a través de RNC1. A este respecto, la terminal puede pasar a través del RNC2 mientras que la función de SRNC puede permanecer como tal en el RNC1. Pero en tal caso, debido a que se usa un recurso entre el RNC1 y RNC2, el recurso de red del UTRAN se desperdicia. Por lo tanto, el recurso desperdiciado se puede reducir a través del procedimiento de relocalización de SRNS. Después de que se completa el procedimiento de relocalización de SRNS, el RNC2 sirve como el SRNC de la terminal y la terminal es conectada a la red de núcleo a través de SGSN2.
Puede haber varias condiciones en donde se realice relocalización de SRNS incluyendo los siguientes dos casos típicos: Caso I: la red misma realiza relocalización de SRNS para cambiar el punto de acceso entre la UTRAN y la red de núcleo; y el caso II: la relocalización de SRNS se realiza en forma simultánea con un procedimiento de cambio de una celda reportada desde la terminal o con un procedimiento de cambio de un registro de localización. Aunque los casos I y II son diferentes en que uno está implicado con la terminal y el otro no, los dos casos no tienen diferencia sustancial con respecto al procedimiento de relocalización de SRNS. Durante el procedimiento de relocalización de SRNS, varios mensajes de señalización son intercambiados entre la terminal y el RNC, entre los RNCs, y entre el RNC y la red de núcleo. El procedimiento de relocalización de SRNS se puede entender a través de los mensajes de señalización intercambiados entre la terminal, el RNC y la red de núcleo. La figura 6 ilustra el procedimiento de relocalización de SRNS en el UMTS. En la figura 6, un RNC de recurso significa un RNC que sirve como un SRNS para una terminal pertinente antes de la relocalización de SRNS, y un RNC objetivo indica un RNC que sirve como un SRNC para una terminal pertinente después de la relocalización de SRNS. Asimismo, un SGSN viejo y un SGSN nuevo indican GSNs que sirven como SGSNs para una terminal pertinente antes y después de la relocalización de SRNS, respectivamente. Aunque se muestra que los SGSNs viejo y nuevo son diferentes, el SGSN viejo y el SGSN nuevo pueden ser los mismos en ciertas circunstancias. Además, el procedimiento mostrado en la figura 6 se puede aplicar tanto al caso I como al caso II. Ahora se resumirán los pasos del procedimiento de relocalización de SRNS. El orden de transmisión de cada mensaje depende de números asignados, pero los mensajes pueden no ser transmitidos en este orden. 1. Ya sea el caso I o el caso II se pueden usar para activar el procedimiento de relocalización. 2. El RNC de fuente envía la información relacionada con relocalización de SGSN viejo tal como información de identificación del RNC objetivo, información de terminal, información de seguridad e información de protocolo de RRC a través de un mensaje requerido de relocalización. 3. El SGSN viejo reconoce a partir de la información recibida si un procedimiento de relocalización de SRNS correspondiente es una relocalización inter-SRNS SRNS que requiere un cambio del SGSN o una relocalización intra-SGSN SRSN realizada en el mismo SGSN. Si el SGSN cambia como se muestra en los dibujos, el SGSN viejo envía un mensaje de Petición de Relocalización Hacia delante al nuevo SGSN para instruir la asignación de un nuevo recurso de red relacionado con la relocalización. 4. El SGSN nuevo envía un mensaje de Petición de Relocalización al RNC objetivo de modo que los recursos necesarios puedan ser asignados cuando el RNC objetivo se convierte en el SRNC. Este procedimiento incluye un paso de preparar varios portadores de radio que el RNC de recurso ha usado para comunicación con la terminal. Después de que el SGSN nuevo recibe un mensaje de Reconocimiento de Petición de Relocalización, una trayectoria para transmitir datos también se genera entre el RNC objetivo y el SGSN nuevo. 5. Después de que el recurso para transmisión de datos entre el
RNC objetivo y el SGSN nuevo se preparan y una relocalización de SRNS se prepara completamente, el SGSN nuevo envía un mensaje de Transmisión de Respuesta de Relocalización al SGSN viejo para informar que el RNC objetivo está listo para recibir datos transmitidos desde el RNC de fuente. 6. Debido a que cada recurso para movimiento de datos y comunicación con la terminal se ha preparado, el SGSN viejo envía un mensaje de Comando de Relocalización al RNC de fuente para informar acerca de portadores de radio que han de ser liberados y portadores de radio para transmitir datos al RNC objetivo. 7. Al recibir el mensaje de Comando de Relocalización, el RNC de fuente envía el mensaje de Compromiso de Relocalización al RNC objetivo a fin de transmitir información de acceso relacionada con la operación del SRNS al RNC objetivo e informar que la función del SRNC ha sido cambiada del SRNC de fuente al RNC objetivo. 8. El RNC de fuente empieza a transmitir datos a los portadores de radio que requieren transmisión de datos al RNC objetivo. En este tiempo, la trayectoria de transmisión de datos va por medio de la red con núcleo, no la transmisión de datos directa entre el RNC de fuente y el RNC objetivo. 9. Al recibir el mensaje de Compromiso de Relocalización del paso 7, el RNC objetivo envía un mensaje de Detección de Relocalización al SGSN nuevo. El RNC objetivo no sirve como el SRNC hasta que envía el mensaje de detección de relocalización. 10. El RNC objetivo envía un mensaje de Información de
Movilidad de UTRAN (Caso I), el mensaje de RRC, o un mensaje de Actualización de Celda/URA (Area de Registro de UTRAN) (Caso II) a la terminal. El mensaje incluye U-RNTI nuevo, información de identificación de terminal nueva, información relacionada con terminal e información relacionada con red de núcleo. En respuesta a estos mensajes, la terminal envía un mensaje de Confirmación de Información de Movilidad de UTRAN al RNC objetivo. Después de que se completa este paso, la terminal y el RNC refija y activa las entidades de PDCP y RLC. Por consiguiente, después de que se completa este paso, la preparación de un enlace ascendente y un enlace descendente se completa, por lo que el RNC objetivo y la terminal pueden intercambiar datos de usuario. 1 1 . Cuando la red de núcleo recibe el mensaje de Detección de Relocalización, la red de núcleo conmuta el plano de usuario a partir del RNC de fuente al RNC objetivo. En el caso de la Relocalización de inter-SGSN, el SGSN nuevo envía un mensaje de Petición de Contexto de PDP de Actualización incluyendo una dirección del SGSN nuevo y otra información de acceso al GGSN. Al recibir el mensaje de Petición de Contexto de PDP de Actualización, el GGSN actualiza información de control relacionada con acceso correspondiente y envía un mensaje de respuesta de contexto de PDP de actualización, un mensaje de respuesta, al SGSN nuevo. 12. Cuando el RNC objetivo recibe exitosamente el mensaje de
Confirmación de Información de Movilidad UTRAN, el RNC objetivo envía un mensaje Completo de Relocalización al SGSN nuevo, para informar al SGSN nuevo la terminación de la relocalización de SRNS. Mientras tanto, en el caso de la relocalización de inter-SGSN SRNS, el SGSN nuevo envía un mensaje de Transmitir Relocalización Completa al SGSN viejo para informar que la relocalización de SRNS ha sido completada. 13. Después de que se ha completado cada paso, el SGSN viejo envía un mensaje de Comando de Liberación de lu al RNC de fuente para liberar la conexión de lu entre el RNC de fuente y el SGSN viejo. La operación y procedimiento básicos de la relocalización de
SRNS se ha entendido a través de la figura 6. Ahora se describirán con detalle los mensajes de RRC transmitidos con respecto a la relocalización de SRNS en el UTRAN.
La figura 7 ilustra un procedimiento de relocalización de SRNS entre el UTRAN y la terminal. En la figura 7, el mensaje de RRC es transmitido en el caso de los Nos. 1 , 7 y 8. Esos mensajes de RRC son los siguientes. (1 ) Mensaje de Actualización de Celda y mensaje de
Confirmación de Actualización de Celda: cuando la terminal se mueve a una nueva celda, el mensaje de Actualización de Celda es enviado desde la terminal. El mensaje de Confirmación de Actualización de Celda es un mensaje de Respuesta del UTRAN al mensaje de Actualización de Celda y contiene comandos tales como liberación/restablecimiento de un portador de radio o restablecimiento de un canal de transporte/canal físico. (2) Mensaje de Actualización de URA y mensaje de Confirmación de Actualización de URA: El URA (Area de Registro de UTRAN) es un área compuesta de una o varias celdas, en donde el UTRAN provee un método efectivo para soportar una movilidad de la terminal. El URA es internamente conocido para el UTRAN. Los URAs fácilmente pueden traslaparse a fin de evitar un efecto de ping-pong de la terminal. Por lo tanto, una celda puede pertenecer a uno o más URAs. La terminal conoce la identidad de URA actual a partir de la difusión de lista de URA en cada celda y realiza el procedimiento de Actualización de URA siempre que el URA sea cambiado. El procedimiento de actualización de URA se inicia cuando la terminal envía el mensaje de actualización de URA a la UTRAN. La UTRAN transmite el mensaje de Confirmación de Actualización de URA en respuesta al mensaje de Actualización de URA a la terminal, a fin de informar a la terminal de la información de identidad de URA recién asignada. Además, igual que el procedimiento de Actualización de Celda, el mensaje de Confirmación de Actualización de URA puede contener un valor de U-RNTI nuevo para identificar la terminal. Igual que el caso de (1 ), el mensaje de Actualización de URA es transmitido usando el SRBO, y el mensaje de Confirmación de Actualización de URA es transmitido usando el SRBO o el SRB1. (3) Mensaje de Información de Movilidad de UTRAN y mensaje de Confirmación de Información de Movilidad de UTRAN: El mensaje de Información de Movilidad de UTRAN es un mensaje de RRC transmitido a partir de UTRAN a la terminal y usado para asignar información de identificación nueva a la terminal o transmitir otra información relacionada con la movilidad de la terminal. En respuesta, la terminal transmite una Confirmación de Información de Movilidad de UTRAN. El mensaje de Información de Movilidad de UTRAN es transmitido a través de SRB1 o el STB2, y el mensaje de Confirmación de Movilidad de UTRAN es transmitido sólo usando el SRB2. Para referencia, en la figura 5, 6 ó 7, después de que la terminal envía el mensaje de Confirmación de Información de Movilidad UTRAN, la terminal en el RNC establece/restablece una entidad de PDCP y una entidad de RLC usando un comando CPDCP-CONFIG-Req y un comando CLRC- CONFIG-Req para restablecer la capa de PDCP y la capa de RLC. Se ha descrito el procedimiento de relocalización de SRNS. A partir de esta descripción, está claro que el procedimiento de relocalización de SRNS se basa principalmente en el intercambio de mensajes entre la terminal y el RNC, y entre el RNC y la red de núcleo. Entre estos mensajes, los mensajes de RRC intercambiados entre la terminal y el RNC generalmente son cifrados para fines de seguridad. Si esos mensajes de RRC son transmitidos sin ser cifrados, puede no ser problemático para el procedimiento de relocalización de SRNS. Pero considerando la situación realista de que los mensajes de RRC transmitidos durante el procedimiento de relocalización de SRNS son cifrados, cuando los mensajes de RRC son transmitidos, puede suceder que los mensajes de RRC transmitidos puedan no ser recibidos apropiadamente debido a la diferencia entre la terminal y el parámetro de cifrado en el UTRAN. Para un mejor entendimiento, el método de cifrado en general se debe considerar primero. El cifrado de datos es un método que evita el acceso no utilizado de datos, por ejemplo, como resultado de escucha furtiva Debido a que existen parámetros de cifrado únicos entre la terminal y el RNC, un usuario que no conoce los parámetros de cifrado puede no cifrar los datos. El método de cifrado adoptado por el 3GPP se realiza en la capa L2, y se puede llevar a cabo en la capa de RLC o la capa de MAC de acuerdo con el modo de operación del RLC. Es decir, cuando el modo de RLC es AM o UM, el cifrado se realiza en la capa de RLC. Cuando el modo de RLC es TM, el cifrado se realiza en la capa de MAC. Cada cifrado se realiza sólo en un mensaje transmitido a través del DCCH. Durante el método de cifrado, un MASK usado para cifrado se genera con base en varios parámetros de entrada. El MASK se añade después a las RLC PDUs o MAC SDUs para generar los datos de cifrado. El receptor mismo genera el mismo MASK que el del transmisor y lo añade a los datos recibidos, descifrando así los datos antes del cifrado. La figura 8 muestra el procedimiento de cifrado. En la figura 8, el bloque de TEXTO PLANO son los datos antes del cifrado y el bloque de CORRIENTE CLAVE es un MASK de cifrado. El bloque de TEXTO PLANO es cifrado al bloque de TEXTO CIFRADO a través de una operación de bits con el bloque de CORRIENTE CLAVE. Después, el bloque de TEXTO CIFRADO es transmitido a una interfaz de radio. Después de recibir el bloque de TEXTO CIFRADO, el receptor lo descifra aplicando el bloque de CORRIENTE CLAVE que es el mismo MASK que el transmitido. Es decir, los datos cifrados son extraídos durante la transmisión, los datos no pueden ser descifrados a menos de que conozca el bloque de CORRIENTE CLAVE. La tecnología del núcleo de cifrado se basa en la generación del bloque de CORRIENTE CLAVE. Para lograr resultados efectivos, el MASK debe tener las siguientes características. Primero, la generación de MASK por rastreo de reversa debe ser imposible. Segundo, cada portador de radio RB debe tener su propio MASK. Tercero, el MASK debe cambiar continuamente con el tiempo. Entre los diversos algoritmos de cifrado que existen, un método referido como F8 ha sido adoptado por los sistemas de comunicación 3GPP. El algoritmo F8 genera el bloque de CORRIENTE CLAVE usando parámetros de entrada que incluyen: - CK (Clave de cifrado, 128 bits): Hay una CKcs para un dominio de servicio basado en interrupción de circuito de una CKps para un dominio de servicio basado en interrupción de paquete. - PORTADOR (Identificador de Portador de Radio, 5 bits) es discriminador de un portador de radio, y existe un valor para cada RB. - DIRECCIÓN (Identificador de Dirección, 1 bit): Es un discriminador de dirección y se fija a 0 para enlace ascendente y 1 para enlace descendente. - LONGITUD (16 bits): Es un indicador de longitud y determina la longitud del bloque de CORRIENTE CLAVE, es decir, el MASK generado. - CONTEO-C (32 bits): Es un número de secuencia de cifrado. Para RBs que usan AM o UM de RLC, se usa un CONTEO-C para cada RB. Para RBs se usan TM de RLC, se usa un valor de CONTEO-C para todos los RBs. Los expertos en la técnica pueden apreciar que otros factores distintos a CONTEO-C entre los factores de entrada de cifrado son todos valores fijados. Sólo CONTEO-C se cambia con el tiempo cuando un RLC PDU es transmitido. - La construcción de CONTEO-C empíricamente consiste de un número de secuencia largo en la parte frontal y un número de secuencia corto en la parte posterior. La figura 9 muestra la estructura de CONTEO-C de acuerdo con el modo de transmisión de RLC. * En el caso de usar RLC TM - Número de secuencia largo: MAC-d HFN de 24 bits (Número de
Hipercuadro) - Número de secuencia corto: CFN de 8 bits (Número de Cuadro de Conexión). * En el caso de usar RLC UM - Número de secuencia largo: RLC HFN de 25 bits (Número de
Hipercuadro) - Número de secuencia corto: RLC UM SN de 7 bits (Número de
Secuencia) *En el caso de usar RLC AM - Número de secuencia largo: RLC HFN de 20 bits (Número de
Hipercuadro) - Número de secuencia corto: RLC AM SN de 12 bits (Número de
Secuencia) El CFN es un contador para sincronizar los canales de transporte de la capa de MAC entre la terminal y el UTRAN. El CFN puede tener un valor entre O y 255 e incrementa por uno para cada cuadro de radio (10 ms). El RLC SN es un número de secuencia usado para identificar cada RLC PDU. Para UM RLC, el RLC SN tiene un valor entre 0 y 127 (7 bits). Para AM RLC, el RLC SN tiene un valor entre 0 y 4095 (12 bitsO, el RLC SN incrementa por 1 para cada RLC PDU. El número de secuencia corto es un contador usado para protocolo de acceso de radio y es algo corto. Por lo tanto, para hacerlo un parámetro más bien largo, un número de secuencia largo conocido como HFN se añade en la parte anterior del número de secuencia corto. Cada HFN se incrementa por 1 cuando el número de secuencia corto envuelve a "0". En el caso del mensaje de RRC, puesto que es transmitido a través de la capa de RLC, usando el modo UM o AM, se puede aplicar el cifrado. Es decir, el mensaje de RRC que ha llegado a la capa de RLC es adecuadamente segmentado o conectado adecuadamente de acuerdo con el tamaño de transmisión para construir la RLC PDU, por lo que la parte de datos de la RLC PDU es cifrada usando el MASK generado en la figura 8. En este tiempo, los diversos parámetros de cifrado usados para generar el MASK deben ser los mismos en el receptor y en el transmisor. Aun cuando la transmisión y la recepción de datos se hace normalmente, si el valor de CONTEO-C se cambia, los datos se pueden restaurar a datos totalmente diferentes.
La parte correspondiente al número de secuencia corto en CONTEO-C está contenido en la información de encabezamiento llevada a la RLC PDU. Por lo tanto, hablando en términos estrictos, si los valores de HFN manejados en la terminal y las RNC no son idénticas unas con otras, la restauración de los datos cifrados fallarán y los datos no pueden ser recibidos normalmente. Con base en el método de cifrado, pueden surgir problemas en los procedimientos 7 y 8 de la figura 7. Para referencia, a través del procedimiento 1 también se usa el mensaje de RRC debido a que las RLC PDUs son transmitidas usando el CCCH y no se realiza el cifrado, por lo que no ocurre problema con el mismo. 1. El problema del procedimiento 7 En el caso I o el caso II, los mensajes de RRC transmitidos a la terminal son transmitidos desde el RNC objetivo usando el SRB adecuado. Sin embargo, puesto que las capas de RLC generadas en RNC objetivo son nuevamente generadas durante el procedimiento de relocalización de SRNS, cada valor de variable de estado y reguladores de tiempo han sido inicializados. Por ejemplo, el número de secuencia de la RLC PDU transmitido de la capa de RLC de la RNC objetivo se ha inicializado como "0", el valor inicial. Los posibles problemas se describirán ahora para cada uno de estos casos. (1 ) En el caso de UTRAN, Información de Movilidad transmitida a través de SRB1 : En este caso, el procedimiento de relocalización se realiza durante el modo de operación de UM RLC. Si el RNC objetivo transmite datos usando el HFN como tal habiendo sido recibido desde el RNC de fuente, debido a que un número de secuencia que ha esperado la terminal no seria recibido por la terminal, la terminal supondría que varios mensajes se han perdido durante la transmisión. Por consiguiente, el receptor supondría que el número de secuencia finaliza y el valor de HFN se incrementa por "1 ". Entonces, el valor de HFN cifrado por la transmisión y el valor de HFN usado para restaurar el cifrado en el receptor son diferentes uno de otro, el mensaje de RRC no puede ser recibido normalmente. (2) El mensaje de Información de Movilidad de UTRAN es transmitido a través de SRNB2: En este caso, el procedimiento de relocalización se realiza durante el modo de operación AM RLC. En general, para facilitar el manejo de acuerdo con la retransmisión, la capa de AM RLC del receptor fija un intervalo del número de secuencia de las RLC PDUs que la capa de RLC del receptor puede recibir. Esta se denomina una ventana receptora, y si una RLC PDU que tiene el número de secuencia más allá del intervalo de la ventana receptora es recibida, los datos se desechan inmediatamente. Debido a que el número de secuencia de la RLC PDU recibida del RNC objetivo se fija a "0", si el valor está dentro de la ventana receptora de la terminal, los datos pueden ser recibidos. Pero si el valor está fuera del intervalo de la ventana, es desechado, por lo que un mensaje de RRC correspondiente no puede ser recibido. Aunque los datos están dentro del intervalo de la ventana y por lo tanto son exitosamente recibidos, la RLC PDU no puede ser restaurada exitosamente debido a la diferencia de HFN como en el caso (1 ). (3) El mensaje de Confirmación de Actualización de Celda/URA es transmitido a través de SRB1 : El mismo problema ocurre como en (1 ) anterior. (4) La confirmación de actualización de Celda/URA es transmitida a través de SRBO: Debido a que se usa CCCH, no ocurre problema con respecto al cifrado. Como se indicó anteriormente, para los mensajes de RRC transmitidos a través del procedimiento 7 desde RNC objetivo, ocurre un problema de que el mensaje de RRC correspondiente no es recibido en los casos distintos al caso (4). Esto significa que no se hace más comunicación de datos entre la terminal y el RNC objetivo después de la relocalización de SRNS. (2) El problema del procedimiento 8 Tanto en el caso I como en el caso II, la terminal transmite un comando de Confirmación de Información de Movilidad de UTRAN usando el SRB2 como el procedimiento final de la relocalización de SRNS. Sin embargo, como en el procedimiento 7, debido a que la capa de RLC para el SRB2 generado en RNC objetivo se ha refijado, el número de secuencia de la RLC PDU que se esperaría que fuera recibido por RNC objetivo se ha inicializado a "0". Sin embargo, debido a que la terminal transmite los datos usando el SRB2 que ha usado, si una RLC PDU va más allá del intervalo de la ventana receptora como en el caso (2), en el cual el problema del procedimiento 7 se ha descrito, la RLC PDU correspondiente es desechada por lo que el mensaje de RRC correspondiente no puede ser recibido. Para resumir, el método de relocaización de SRNS convencional tiene un problema de que debido al cifrado de datos y a la reinicialización de la capa de RLC ubicada en RNC objetivo, la capa de RLC del receptor no puede recibir apropiadamente el mensaje de RRC correspondiente.
ESENCIA TECNICA DE LA PRESENTE INVENCION
Por lo tanto, la presente invención es proveer una solución a los problemas de la técnica convencional.
DESCRIPCION DETALLADA DE LA INVENCION
Para lograr el objeto anterior, se provee un método de relocalización de SRNS que incluye: determinar una relocalización de SRNS en una red; reservar un recurso de requerimiento en una relocalización de subsistemas de radio de servicio en una red; transmitir un mensaje de control de recurso de radio (RRC) correspondiente a la relocalización de subsistema de red de radio de servicio por una RNC objetivo a la terminal para que el RNC objetivo que sirve como el SRNC después de la relocalización de SRNS comunique con la terminal; transmitir un mensaje de RRC de respuesta relacionado con la relocalización de SRNS al RNC objetivo por la terminal. En el método de relocalización SRNS de la presente invención, el controlador de red de radio transmite datos fijando una capa de control de enlace de radio correspondiente y ajustando un número de cuadro requerido para cifrado por lo que la terminal puede restaurar exitosamente datos cifrados antes de que el controlador de red de radio transmita el mensaje de control de recurso de radio correspondiente relacionado con la relocalización de substistema de red de radio de servicio a la terminal. En el método de relocalización de SRNS de la presente invención, el número de cuadros es incrementado por 1 más que un valor usado en el presente tiempo, y datos de unidad de la capa de control de enlace de radio correspondiente son cifrados usando el valor y transmitidos. En el método de relocalización de SRNS de la presente invención, la capa de control de enlace de radio transmite un comando para fijar la capa de control de enlace de radio y el número de cuadros a la capa de control de enlace de radio correspondiente. En el método de relocalización de SRNS de la presente invención, un controlador de red de radio original que sirve como un controlador de red de radio de servicio antes de que la relocalización de subsistema de red de radio de servicio transfiera información de estado de una capa de control de enlace de radio usada en el presente tiempo a un controlador de red de radio objetivo de modo que la terminal pueda recibir exitosamente un mensaje de control de recurso de radio antes de que el controlador de red de radio objetivo transmita un mensaje de control de recurso de radio relacionado con la relocalización de subsistema de red de radio de servicio a la terminal. En el método de relocalización de SRNS del método de la presente invención, la información de estado transferido incluye un parámetro relacionado con la capa de control de enlace de radio operada en un modo no reconocido. En el méotdo de relocalización de SRNS de la presente invención, un primer número de secuencia de datos de unidad de la capa de control de enlace de radio que incluye el mensaje de control de recurso de radio relacionado con la relocalización del substistema de red de radio de servicio transferido desde el controlador de red de radio objetivo a la terminal es transmitido al fijarse con un VT (US) de un parámetro relacionado con la capa de control de enlace de radio operada en el modo no reconocido. En el método de relocalización de SRNS de la presente invención, la información de estado transferida incluye un parámetro o datos relacionados con la capa de control de enlace de radio operada en un modo reconocido. En el método de relocalización de SRNS de la presente invención, un primer número de secuencia de datos de unidad de la capa de control de enlace de radio que incluye el mensaje de control de recurso de radio relacionado con la relocalización de subsistema de red de radio de servicio transferido desde el controlador de red de radio objetivo a la terminal es transmitido al fijarse con un VT(S) en un parámetro relacionado con la capa de control de enlace de radio operada en el modo reconocido. En el método de relocalización de SRNS de la presente invención, la capa de control de enlace de radio del controlador de red de radio objetivo transfiere datos de unidad de la capa de control de enlace de radio y son retransmitidos después de ser recibidos del controlador de red de radio original. En el método de relocalización de SRNS de la presente invención, el controlador de red de radio original termina la transmisión del mensaje de control de recurso de radio que es transmitido o espera la transmisión antes de transferir un parámetro relacionado con una capa de control de enlace de radio operada en el modo reconocido al controlador de red de radio objetivo. En el método de relocalización de SRNS de la presente invención, la capa de control de enlace de radio del controlador de red de radio objetivo transmite un comando de movimiento de ventana receptor a una capa de control de enlace de radio de la terminal para impedir la transmisión de datos de unidad de la capa de control de enlace de radio que tienen un número de secuencia por debajo de un número de secuencia de VT (S)-1.
En el método de relocalización de SRNS de la presente invención, la capa de control de recurso de radio del controlador de red de objetivo instruye a la capa de control de enlace de radio a Iniciar el comando de movimiento de ventana receptora. En el método de relocalización de SRNS de la presente invención, la capa de control de recurso de radio transfiere el parámetro o datos como se recibieron del controlador de red de radio original a la capa de control de enlace de radio. En el método de relocalización de SRNS de la presente invención, un valor de un campo de un indicador de longitud de los datos de unidad de la primera capa de control de enlace de radio incluyendo el mensaje de control de recurso de radio transmitido desde el controlador de red de radio objetivo a la terminal después de la relocalización del subsistema de red de radio de servido indica información de que los datos de unidad de la capa de control de enlace de radio correspondiente incluye el mensaje de control de recurso de radio desde una primera porción del mismo. En el método de relocallzación de SRNS de la presente invención, una inicialización de la capa de control de enlace de radio se realiza inicializando una variable de estado entre la capa de control de enlace de radio de la terminal y una capa de control de enlace de radio del controlador de red de radio y sincronizando un número de cuadros de modo que la terminal pueda recibir exitosamente 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 relacionado con la relocalización del subsistema de red de radio de servicio a la terminal. En el método de relocalización de SRNS de la presente invención, la capa de control de enlace de radio del controlador de red de radio objetivo transmite datos de unidad de inicialización, un comando para realizar inicialización del control de enlace de radio, a la capa de control de enlace de radio de la terminal. En el método de relocalización de SRNS de la presente invención, la capa de control de recurso de radio del controlador de red de radio objetivo transfiere un comando de iniciación de la inicialización de la capa de control de enlace de radio para permitir que la capa de control de enlace de radio del controlador de red de radio objetivo inicie la inicialización de la capa de control de enlace de radio. En el método de relocalización de SRNS de la presente invención, una capa de control de enlace de radio del controlador de red de radio objetivo y la terminal se fija de modo que el controlador de red de radio objetivo pueda recibir exitosamente un mensaje de control de recurso de radio correspondiente antes de que la terminal transmita el mensaje de control de recurso de radio relacionado con la relocalización del subsistema de red de radio del servicio al controlador de red de radio objetivo. En el método de relocalización de SRNS de la presente invención, el valor de número de cuadros es sintonizado durante la fijación de las capas de control de enlace de radio del controlador de red de radio objetivo y la terminal. En el método de relocalización de SRNS de la presente invención, la fijación del valor de número de cuadros es transferida desde una capa superior. En el método de relocalización de SRNS de la presente invención, la fijación del valor de número de cuadros se realiza por el incremento de número de cuadros usado en la terminal y el controlador de red de radio objetivo por 1. En el método de relocalización de SRNS de la presente invención, la fijación de los números de cuadros usados en la capa de control de enlace de radio de la terminal y la capa de control de enlace de radio del controlador de red de radio objetivo se realiza incrementado por 1 sobre la base del valor más grande entre el número de cuadros de enlace ascendente y el número de cuadros de enlace descendente usado en la capa de control de enlace de radio de la terminal y la capa de control de enlace de radio del controlador de red de radio objetivo. En el método de relocalización de SRNS de la presente invención, las capas de control de recurso de radio de la terminal y el controlador de red de radio objetivo transfieren un comando para fijar/refijar una capa de control de enlace de radio correspondiente, respectivamente. En el método de relocalización de SRNS de la presente invención, el fijación/refijación de portadores de radio de señalización y portadores de radio en la terminal y el controlador de red de radio objetivo se utilizan después de que la terminal transfiere el mensaje de control de recurso de radio de respuesta relacionado con la relocalización de subsistema de red de radio de servicio al controlador de red de radio objetivo. En el método de relocalización de SRNS de la presente invención, un valor de número de cuadros se fija como el valor inicial de número de cuadros contenido en el mensaje de control de recurso de radio de respuesta relacionado con la relocalización de subsistema de red de radio de servicio que la terminal ha transferido al controlador de red de radio objetivo durante el procedimiento de fijación/refijación de los portadores de radio de señalización y los portadores de radio que existen entre la terminal y el controlador de red de radio objetivo. En el método de relocalización de SRNS de la presente invención, el valor inicial del número de cuadros contenido en el mensaje de control de recurso de radio es un valor inicial almacenado en un módulo de cifrado de la terminal definido en el estándar de UMTS, un sistema IMT2000 asincrono. Ventajas, objetos y características adicionales de la invención se expondrán en parte en la descripción que sigue y en parte serán evidentes para los expertos en la técnica al examinar lo siguiente o se pueden aprender a partir de la práctica de la invención. Los objetos y ventajas de la invención se realizarán y lograrán como se indica particularmente en las reivindicaciones anexas. BREVE DESCRIPCION DE LOS DIBUJOS La figura 1 es una estructura de red de un sistema de telecomunicación móvil universal (UMTS); la figura 2 muestra una estructura de un protocolo de acceso de radio; La figura 3 muestra una estructura de una RLC PDU usada en una capa de RLC; la figura 4 muestra una estructura de una memoria intermedia de AM RLC y un indicador de estado de una memoria intermedia de RLC de un transmisor; la figura 5 ilustra el concepto de un procedimiento de relocalización de SRNS; la figura 6 muestra un procedimiento de relocalización de SRNS en un sistema UMTS; la figura 7 ilustra un procedimiento de relocalización de SRNS en un UTRAN; la figura 8 muestra un procedimiento de cifrado realizado en una sección de radio 3GPP; la figura 9 muestra una construcción de un CONTEO-C de acuerdo con un modo de transmisión de RLC; la figura 10 es un dibujo que ilustra un procedimiento de un método propuesto para recibir un mensaje de Confirmación de Información de Movilidad de UTRAN;
la figura 1 1 es un dibujo que ilustra un procedimiento de método propuesto para recibir un mensaje de RRC a través de un SRB1 ; y la figura 12 es un dibujo que ilustra un procedimiento de método propuesto para recibir el mensaje de RRC a través de un SRB2.
MODO PARA LLEVAR A CABO LAS MODALIDADES PREFERIDAS
La presente invención se describirá ahora con referencia a los dibujos anexos. Al dirigir resolver el problema actual relacionado con la relocalización de SRNS, la presente invención propone un método para recibir exitosamente un mensaje de RRC transmitido al corregir operaciones relacionadas con fijación/refijación de una capa de RLC, un procedimiento de cifrado, o similar, tal como ajustando un valor de HFN usado para cifrar o proveer información de SRBs fijado en un SRNC previo al ocurrir relocalización de SRNS. Para empezar, una solución a un problema que surge en el procedimiento 8 de la figura 7 se describirán ahora. El problema de procedimiento 8 es que un RNC objetivo no puede recibir exitosamente un mensaje de RRC llamado la Confirmación de Información de Movilidad de UTRAN transmitida usando un SRB2 desde una terminal. Una solución a este problema es sincronizar HFN entre la terminal y el RNC objetivo para recibir el mensaje de RRC.
La figura 10 ilustra el método de resolver el problema, que sincroniza las capas de RLC de ambos extremos por lo que el RNC objetivo no puede recibir normalmente un mensaje de Confirmación de Información de Movilidad de UTRAN, un mensaje de RRC que la terminal transmite en el método de relocalización de SRNS actual. En otras palabras, mientras que procede el procedimiento de relocalización de SRNS, las capas de RLC de la terminal y el RNC objetivo son simultáneamente fijados/refijados para inicializar variables de estado y ajustar valores de HFN para que sean los mismos. Puede haber varios métodos para usar el mismo valor de HFN, y se proponen tres métodos en la presente invención. El primero es que los valores de HFN respectivamente usados en el SRB2 de la terminal y RNC objetivo se implementan por 1 . El segundo es que un valor de HFN que ha de ser usado posteriormente es recibido de la capa de RRC, una capa superior. El tercero es usar el hecho de que un par de SRB2 existe tanto para arriba como para abajo. A saber, de los valores de HFN ascendente o descendente usados para cifrar datos transmitidos usando SRB2, el valor mayor se selecciona y se considera como un valor de HFN convencional. De hecho, puesto que un valor diferente de los valores de HFN previos se debe usar, los valores de HFN ascendente o descendente se fijan como valores obtenidos añadiendo 1 al valor máximo.
Esos comandos pueden ser transferidos usando CRLC-CONFIG-Req, un comando de fijación transmitido desde RRC a la capa de RLC. Después de que la terminal recibe exitosamente el mensaje RRC del procedimiento 7, refija la capa de RRC correspondiente y realiza un procedimiento de A1 que fija un valor de HFN, mientras que UTRAN transmite el mensaje de RRC del procedimiento 7 y después realiza el procedimiento A2 de la figura 10. Si los procedimientos A1 y A2 se realizan antes del procedimiento 8 de la figura 10, la capa UTRAN RLC recibirá una RLC PDU que tiene el número de secuencia que ha esperado recibir. Habiéndose cifrado al usar el mismo HFN, el mensaje de Corifirmación de Información de Movilidad de UTRAN puede ser recibido exitosamente por el RNC objetivo. Ahora se describirá una solución al procedimiento 7 de la figura
6. Un problema del procedimiento 7 de la figura 7 es si la terminal puede recibir exitosamente un mensaje de RRC descendente transmitido usando SRB1 o SRB2. Diferentes soluciones se pueden proponer por separado para SRB1 y SRB2 como sigue. (1 ) En el caso de transferir mensaje de RRC usando SRB1 : En este caso, un mensaje de Información de Movilidad de UTRAN o mensajes de Actualización de CE/URA son transferidos usando UM RLC y DCCH.
La figura 11 muestra dos métodos para resolver los problemas como se proponen en la presente invención. El método A: una solución en consideración del HFN de la terminal cuando la capa de RLC se vuelve a fijar: Como se muestra en el procedimiento "A" de la figura 1 1 , HFN de la terminal se toma en consideración cuando RRC transfiere el comando CRLC-CONFIG-Req a la capa de RLC en el RNC objetivo para volver a fijar la capa de RLC de RNC objetivo antes del procedimiento 7. En general, la capa de RLC objetivo pasa por el procedimiento de fijación/refijación de la capa de RLC durante un procedimiento de relocalización SRNS. En este tiempo, sin embargo, simplemente la fijación/refijación e inicialización variables de estado no son suficientes. La razón es porque, como se indicó antes, cuando la capa de RLC de la terminal recibe la RLC PDU que tiene el número de secuencia de "0" incrementa el valor de HFN para restaurar los datos cifrados. Como una solución a este problema, un método en donde RNC objetivo incrementa el valor de HFN por "1" cuando se refija la capa de RLC de SRB1 puede ser adoptado. Con este método, debido a que la sincronización de HFN se hace entre la terminal y RNC objetivo, la Información de Movilidad de UTRAN o el mensaje de Confirmación de Actualización de celda/URA puede ser recibido exitosamente. En este tiempo, si los números de secuencia de las RLC PDUs no son recibidos exitosamente, la primera RLC PDU recibida se puede desechar siendo considerada como datos conectados a la RLC PDU previa. Por lo tanto, un valor de indicación de inicio de datos se inicia en el campo indicador de longitud de la RC PDU transmitida justo después de la relocalización de SRNS y después es transmitida. Para este propósito, la capa de RRC puede transferir un comando que instruye eso a la capa de RLC. Método "B": Un método para recibir información relacionada con SRB1 de una RNC de fuente: Como se muestra en los procedimientos B1 y B2 en la figura 11 , en UTRAn durante el procedimiento de relocalización de SRN, una RNC de fuente informa a el RNC objetivo de varios parámetros relacionados con SRB1 de fijación. Para que la RLC PDU recibida por la terminal sea restaurada exitosamente, necesita tener el mismo valor de HFN que se usó en la terminal y su número de secuencia necesita estar en un intervalo adecuado usado en el RNC de fuente. Por lo tanto, si el número de secuencia de la RLC PDU, la variable de estado y la HFN usada en la capa de RLC de el RNC de fuente son transferidas al RNC objetivo y el RNC objetivo transfiere la RLC PDU usando esos valores, sería como si la capa de RLC de la terminal recibiera la RLC PDU del RNC de fuente. Por ejemplo, el RNC de fuente informa al RNC objetivo del valor de HFN y un VT (US), un número de secuencia de la RLC PDU que ha de ser transmitida enseguida, a través del procedimiento B1. Y el RNC objetivo informa del VT(US) usando un comando CRLC-CONFIG-Req para poder transmitir el número de secuencia de RLC PDU transmitida primero después de refijar el procedimiento de la capa de RLC fijado desde VT (US) (procedimiento B2). Igual que en el caso del método "A", si los números de secuencia recibidos de RLC PDUs no son exitosamente recibidos, la primera RLC PDU recibida puede ser desechada al ser considerada como datos conectados por la RLC PDU previa. Para evitar esto, un valor de indicador de inicio de datos se inicia en el campo indicador de longitud de la RLC PDU transmitida justo después de la relocalización de SRNS, y después transferida. Para este propósito, la capa de RRC puede transferir un comando que instruya eso a la capa de RLC. (2) En el caso de transferir un mensaje de RRC usando SRB2: En este caso, el mensaje de Información de Movilidad UTRAN es transferido usando AM RLC y DCCH. Como en el caso (1 ), puede haber varios métodos, y la presente invención propone un método (método "A") que usa un procedimiento de refijación y un método (método "B") para recibir información relevante del RNC de fuente. Método "A": Método para realizar el procedimiento de refijación: La figura 12 muestra una solución usando el procedimiento de refijación en los procedimientos A1 y A2. El procedimiento de refijación es fijar las capas RLC entre la terminal y la UTRAN operada en el modo AM. Cuando este procedimiento se termina exitosamente, los HFNs de las dos capas RLC tienen los mismos valores, y la variable de estado y los números de secuencias se inicializan. Por lo tanto, si el procedimiento de refijación entre los RLCs del
RNC objetivo y la terminal se termina exitosamente antes de que el mensaje de RRC sea transferido usando SRB2, la RLC PDU transmitida desde el RNC objetivo es transferida con el número de secuencia inicializado, y debido a que los valores de HFN usados en ambos extremos son los mismos uno con otro, la RLC PDU recibida puede ser fácilmente restaurada. Para el procedimiento de refijación, la capa de RLC del RNC objetivo transfiere una PDU de refijación (procedimiento A1 ) a la terminal, y en respuesta, la capa de RLC de la terminal transfiere una ACK PDU de refijación (procedimiento A2) al RNC objetivo, terminando así el procedimiento de refijación. En ese tiempo, a diferencia de la RLC PDU general, la PDU de refijación no tiene un número de secuencia que no ha sido cifrado, la PDU de refijación transferida a través de SRB2 puede ser exitosamente recibida por la terminal. Especialmente, usando el procedimiento de refijación resuelve el problema relacionado tanto con la transmisión como con la recepción del enlace ascendente y el enlace descendente para SRB2. Por consiguiente, no hay problema en la recepción de mensaje de RRC usando el enlace ascendente. Por lo tanto, el problema del procedimiento 8 también se puede resolver sin necesidad de usar una solución propuesta en la figura 10. A este respecto, para proceder con el procedimiento de refijación en el RNC objetivo antes de realizar el procedimiento 7, la capa de RLC necesita ser instruida para realizar el procedimiento de refijación. Este comando puede ser transferido desde la RRC a la RLC en forma de CRLC-CONFIG-Req o en una nueva forma de comando. Método "B": Método para recibir información relevante del RNC de fuente: Como se muestra en los procedimiento B1 y B2 de la figura 12, el método "B", es que el RNC de fuente informa al RNC objetivo de varios parámetros relacionados con SRB2 de fijación. Es una solución similar al caso de SRB1 , pero en el caso de SRB2, debido a que usa la AM RLC, se debe considerar la retransmisión de RLC PDU. Es decir, además de ajustar simplemente el número de secuencia de la RLC PDU que ha de ser transmitida y el valor de HFN, los datos que han sido transmitidos previamente a la terminal pero que no se ha recibido respuesta positiva a los mismos se pueden considerar, para lo cual se puede seguir los siguientes tres métodos. El primero es un método en el que la RLC PDU o el mensaje de RRC que está siendo transmitido junto con el número de secuencia, la variable de estado y HFN o similar que se ha usado en la capa de RLC del RNC de fuente de la UTRAN son transferidos al RNC objetivo. Si el RNC objetivo transfiere la RLC PDU usando estos parámetros, es como si la capa de RLC de la terminal recibiera la RLC PDU del RNC de fuente. Por ejemplo, el RNC de fuente informa al RNC objetivo del valor de HFN, las RLC PDUs siendo valores de VT(S) y VT(A) retransmitidos a través del procedimiento B1. El RNC objetivo almacena las RLC PDUs recibidas desde el RNC de fuente después del procedimiento de refijación de la capa de RLC en una memoria intermedia y asigna el mensaje de Información de Movilidad de UTRAN a una PDU que inicia con VT(S) (procedimiento B2). Por lo tanto, puesto que el RNC objetivo puede mantener el mismo estado de memoria intermedia de SRB2 que el RNC de fuente para transmitir datos, la terminal puede restaurar los datos transmitidos a través de SRB2. El segundo método es que el RNC de fuente informa al RNC objetivo del valor de HFN y VT(S) a través del procedimiento B1 , y el RNC de fuente interrumpe la transmisión de las RLC PDUs antes de realizar una relocalización de SRNS. De conformidad con este método, debido a que la RLC de la terminal ha completado el proceso sobre los mensajes de RRC previos, la RLC PDU recibida primero después de la relocalización del SRNS contiene mensaje de Información de Movilidad de UTRAN que tiene el VT(S). El tercer método es que el RNC de fuente informa que el RNC objetivo del valor de HFN y el VT(S) a través del procedimiento B1 , y el RNC de fuente instruye el movimiento de una ventana receptora a la capa de RLC de la terminal de modo que la capa de RLC de la terminal puede no requerir los datos anteriores. Este método es similar al segundo método y puede ser un método sustancial a remover los mensajes de RNC antes de realizar la relocalización de SRNS y resolver el problema de retransmisión. Desde luego, a fin de transferir el comando para mover la ventana receptora, la capa de RRC necesita instruir a la capa de RLC de acuerdo con lo mismo. En el segundo y tercer métodos, puede haber un caso en el que un valor indicador de inicio de datos sea fijado en el indicador de longitud como el problema de transmisión de mensaje de RRC descendente a través de SRB1. En otra palabras, puesto que las RLC PDUs fijadas con el número de secuencia de VT(S)-1 y transmitidas pueden no ser apropiadamente recibidas, el valor indicador de inicio de datos es enviado en el campo de indicador de longitud de la RLC PDU transmitida inmediatamente después de la relocalización de SRNS, y después transmitida. Para este propósito, la capa de RRC puede transmitir un comando correspondiente a la capa de RLC.
Se han descrito los problemas que pueden surgir en los procedimientos 7 y 8 en la figura 7. Aun cuando la transmisión y recepción de los mensajes de RRC son exitosos, debido a que la capa de RLC para varios portadores de radio es fijada/refijada en el RNC objetivo, la capa de RLC fijada/refijada en el RNC objetivo y la capa de RLC de la terminal estarían en el estado en donde pudieran intercambiar información una con otra para una comunicación normal después de completarse el procedimiento 8. Incluso para el caso de portadores de radio distintos a los SRBs, se puede realizar intercambio de datos usando cifrado. Por lo tanto, los esfuerzos para evitar una liberación de conexión de acuerdo con el cifrado se necesita hacer cuando la capa de RLC sea fijada/refijada, para lo cual la terminal puede transferir valor de INICIO, un valor inicial, para HFN a través del procedimiento 8 de la figura 7. El UTRAN que ha recibido un valor de INICIO y la terminal que ha recibido una respuesta positiva al mensaje fija/refija la capa de RLC para cada portador de radio y fija 20 bits superiores de HFN como el valor de INICIO. Si el tamaño de HFN excede 20 bits, los bits restantes serán todos inicializados a ?'. En este tiempo, el valor de INICIO se define en el estándar del 3GPP y es manejado por un módulo de cifrado de la terminal. Este valor puede ser actualizado de acuerdo con el cambio de valor de HFN mientras que la terminal es desconectada o conectada. Desde luego, los procedimientos anteriormente descritos se aplican a cada SRBs y portadores de radio generales. Sin embargo, con respecto a esto, dado que la sincronización del valor de HFN ya se ha hecho antes del procedimiento 8 para el SRB2, no es necesario refijar el valor de HFN para el SRB2.
Aplicabilidad industrial Como se ha descrito hasta ahora, el método de relocalización de SRNS de la presente invención es capaz de cambiar SRNC (Controlador de Red de Radio de Servicio) para un uso efectivo de un recurso de radio en un sistema U TS, un sistema IMT-2000. Especialmente, los problemas que pueden ocurrir cuando el procedimiento de relocalización de SRNS procede usando los mensajes de RRC de cifrado se resuelven, por lo que se puede lograr la relocalización de SRNS exitosa.
Claims (1)
- NOVEDAD DE LA INVENCION REIVINDICACIONES 1.- Un método para realizar relocalización de SRNS que comprende: recibir información de recurso de radio que incluye un parámetro de cifrado a partir de una RNC de fuente por una RNC objetivo; modificar el parámetro de cifrado para coincidir con un parámetro de descifrado de una terminal de usuario correspondiente a una terminal de usuario usada cuando se reciben datos fuera de secuencia; cifrar datos sobre la base de un parámetro de cifrado modificado; y transmitir los datos de cifrado del RNC objetivo a la terminal de usuario. 2. - El método de conformidad con la reivindicación 1 , caracterizado además porque el RNC objetivo y la terminal son operadas en un modo UM. 3. - El método de conformidad con la reivindicación 2, caracterizado además porque comprende: transferir una unidad de datos cifrados a través de un portador de radio de servicio (SRB1 ). 4. - El método de conformidad con la reivindicación 2, caracterizado además porque comprende: transferir los datos cifrados a través de UM DCCH. 5. - El método de conformidad con la reivindicación 1 , caracterizado además porque los datos fuera de secuencia incluyen datos que tienen un número de secuencia de transmisión que no sigue consecutivamente un número de secuencia de transmisión de una última PDU transmitida desde el RNC de fuente de la terminal de usuario. 6. - El método de conformidad con la reivindicación 1 , caracterizado además porque el parámetro de cifrado y el parámetro de descifrado son parámetros de HFN. 7. - El método de conformidad con la reivindicación 1 , caracterizado además porque el paso de modificación comprende: ajustar un valor de HFN del parámetro de cifrado para igualar un valor de HFN del parámetro de descifrado cuando los datos fuera de secuencia son recibidos. 8. - El método de conformidad con la reivindicación 7, caracterizado además porque el paso de ajuste comprende: incrementar el valor de HFN del parámetro de cifrado para igualar un valor incrementado del parámetro de descifrado. 9.- El método de conformidad con la reivindicación 1 , caracterizado además porque el paso de transmisión comprende: transmitir un indicador de inicio de datos con los datos cifrados. 10. - El método de conformidad con la reivindicación 9, caracterizado además porque el indicador de inicio de datos indica que los datos cifrados no se incluyen como parte de una SDU previamente transmitida a la terminal de usuario. 1 1. - Un método para realizar relocalización de SRNS que comprende: recibir información de fuente de radio por una RNC objetivo a partir de una RNC de fuente; y transmitir una unidad de datos desde el RNC objetivo a una terminal de usuario, la unidad de datos incluyendo un número de secuencia de transmisión que sigue consecutivamente un número de secuencia de transmisión de una última unidad de datos transmitida desde el RNC de fuente a la terminal de usuario. 12. - El método de conformidad con la reivindicación 1 1 , caractenzado además porque comprende: cifrar la unidad de datos antes del paso de transmisión. 13. - El método de conformidad con la reivindicación 12, caracterizado además porque el paso de cifrado comprende: cifrar la unidad de datos con el mismo parámetro de cifrado a la terminal de usuario usada para cifrar una unidad de datos transmitida desde el RNC de fuente a la terminal de usuario. 14. - El método de conformidad con la reivindicación 3, caracterizado además porque el mismo parámetro de cifrado incluye un mismo valor de HFN. 15. - El método de conformidad con la reivindicación 1 1 , caracterizado además porque el RNC objetivo y la terminal de usuario se operan en un modo UM. 16.- El método de conformidad con la reivindicación 1 1 , caracterizado además porque comprende: transmitir la unidad de datos a través de UM DCCH. 17.- El método de conformidad con la reivindicación 11 , caracterizado además porque comprende: transmitir la unidad de datos a través de un portador de radio de servicio (SRB1 ). 18. - El método de conformidad con la reivindicación 1 1 , caracterizado además porque el paso de transmisión comprende: transmitir un indicador de inicio de datos junto con la unidad de datos. 19. - El método de conformidad con la reivindicación 18, caracterizado además porque el indicador de inicio de datos indica que la unidad de datos no se incluye como parte de una SDU previamente transmitida a la terminal de usuario. 20.- Un método para realizar relocalización de SRNS que comprende: refijar información de transmisión de una RNC objetivo; y transmitir un mensaje que instruye a una terminal de usuario a refijar información de recepción a valores que coinciden con dicha información de transmisión refijada. 21.- El método de conformidad con la reivindicación 20, caracterizado además porque el paso de refijación comprende: refijar un número de secuencia de transmisión a un valor inicial en el RNC objetivo, en donde la información de recepción de refijación incluye un número de secuencia de transmisión de una unidad de datos enseguida esperada fijada a dicho valor inicial. 22.- El método de conformidad con la reivindicación 20, caracterizado además porque el paso de refijación comprende: refijar una variable de estado a un valor inicial en el RNC objetivo, en donde el mensaje incluye información que instruye a la terminal de usuario para fijarse a dicha variable de estado. 23.- El método de conformidad con la reivindicación 20, caracterizado además porque el mensaje es un mensaje descifrado. 24.- El método de conformidad con la reivindicación 20, caracterizado además porque comprende: recibir un mensaje desde la terminal de usuario que indica que la terminal de usuario ha refijado la información de recepción. 25. - El método de conformidad con la reivindicación 20, caracterizado además porque el paso de refijación comprende: fijar un parámetro de cifrado a un valor inicial, en donde la información de recepción refijada incluye un parámetro de descifrado que coincide con el valor inicial del parámetro de cifrado. 26. - El método de conformidad con la reivindicación 25, caracterizado además porque el parámetro de cifrado y el parámetro de descifrado incluyen un mismo valor de HFN. 27. - El método de conformidad con la reivindicación 20, caracterizado además porque el paso de refijación comprende: enviar SDUs en el RNC objetivo y en donde el mensaje instruye a la terminal de usuario para enviar las SDUs. 28. - El método de conformidad con la reivindicación 20, caracterizado además porque comprende: transmitir una unidad de datos desde el RNC de objetivo a la terminal de usuario a través de un portador de radio de servicio (SRB2). 29.- El método de conformidad con la reivindicación 20, caracterizado además porque el RNC objetivo y la terminal de usuario se operan en un modo AM. 30.- El método de conformidad con la reivindicación 29, caracterizado además porque comprende: transmitir un parámetro de cifrado e información de número de secuencia de transmisión desde una RNC de fuente al RNC objetivo, en donde el parámetro de cifrado coincide con un parámetro de descifrado usado en la terminal de usuario y un parámetro de cifrado en el RNC de fuente usada para transmitir una unidad de datos a la terminal de usuario, y en donde la información del número de secuencia de transmisión es indicativo de un número de secuencia de transmisión enseguida esperado en la terminal de usuario. 31.- El método de conformidad con la reivindicación 20, caracterizado además porque comprende: transmitir una unidad de datos desde el RNC objetivo hasta la terminal de usuario, la unidad de datos incluyendo un indicador de inicio de datos que indica que la unidad de datos no se incluye como parte de una SDU previamente transmitida a la terminal de usuario. 32.- El método de conformidad con la reivindicación 20, caracterizado además porque comprende: transmitir una unidad de datos desde el RNC objetivo hasta la terminal de usuario a través de AM DCCG. 33.- Un método para realizar relocalización de SRNS que comprende: suministrar información de recurso de radio que incluye un parámetro de cifrado que una RNC de fuente ha usado para transmitir PDUs a una terminal de usuario a partir del RNC de fuente a una RNC objetivo en un UTRAN y un número de secuencia de transmisión correspondiente a una de la siguiente PDU que ha de ser transmitida a la terminal de usuario por el RNC de fuente y una última PDU que ha sido transmitida desde el RNC de fuente de la terminal de usuario; generar una PDU/RRC sobre la base del número de secuencia de transmisión; cifrar el mensaje de PDU/RRC con el parámetro de cifrado; y transmitir el mensaje cifrado desde el RNC objetivo hasta la terminal de usuario. 34. - El método de conformidad con la reivindicación 6, caracterizado además porque el RNC objetivo y la terminal de usuario se operan en un modo AM RLC. 35. - Un método para realizar procedimiento de relocalización en un sistema de comunicación que comprende: inicializar un transmisor para comunicar con un receptor, dicho paso de inicialización comprende: fijar un nuevo número de secuencia de transmisión a un primer valor e fijar un parámetro de descifrado a un segundo valor; transmitir una PDU incluyendo el número de secuencia inicial y el parámetro de descifrado desde el transmisor al receptor; determinar por el receptor que el número de secuencia inicial en la PDU no es igual a un siguiente número de secuencia esperado por el receptor; fijar un parámetro de descifrado en el receptor en el segundo valor; y descifrar la DPU. 36.- Una unidad de transmisión que comprende: una RNC objetivo para recibir información de recurso de radio incluyendo un parámetro de cifrado desde una RNC de fuente; un procesador para modificar el parámetro de cifrado para coincidir con un parámetro de cifrado de una terminal de usuario y cifrar una unidad de datos sobre la base del parámetro de cifrado modificado; y un transmisor para transmitir los datos cifrados desde el RNC objetivo hasta la terminal de usuario; en donde el parámetro de descifrado corresponde a uno de los usos de la terminal de usuario cuando se reciben datos fuera de secuencia. 37.- La unidad de transmisión de conformidad con la reivindicación 36, caracterizada además porque el RNC objetivo y la terminal de usuario se operan en un modo UM. 38. - La unidad de transmisión de conformidad con la reivindicación 37, caracterizada además porque el transmisor transmite una unidad de datos cifrados a través de un portador de radio de servicio (SRB1 ). 39. - La unidad de transmisión de conformidad con la reivindicación 36, caracterizada además porque el transmisor transmite la unidad de datos cifrados a través de UM DCCH. 40. - La unidad de transmisión de conformidad con la reivindicación 36, caracterizada además porque los datos fuera de secuencia incluyen datos que tienen un número de secuencia de transmisión que no sigue consecutivamente un número de secuencia de transmisión de una última PDU transmitida desde el RNC de fuente a la terminal de usuario. 41. - La unidad de transmisión de conformidad con la reivindicación 36, caracterizada además porque el parámetro de cifrado y el parámetro de descifrado son parámetros de HFN. 42. - La unidad de transmisión de conformidad con la reivindicación 36, caracterizada además porque el procesador ajusta un valor de HFN del parámetro de cifrado para igualar un valor de HFN del parámetro de descifrado cuando se reciben datos fuera de secuencia. 43. - La unidad de transmisión de conformidad con la reivindicación 42, caracterizada además porque el procesador incrementa el valor de HFN del parámetro de cifrado para igualar un valor incrementado de parámetro de descifrado. 44. - La unidad de transmisión de conformidad con la reivindicación 36, caracterizada además porque el transmisor transmite un indicador de inicio de datos junto con la unidad de datos cifrados. 45.- La unidad de transmisión de conformidad con la reivindicación 44, caracterizada además porque el indicador de inicio de datos indica que la unidad de datos cifrados no se incluyen como parte de una SDU previamente transmitida a la terminal de usuario. 46.- Una unidad de transmisión que comprende: una RNC objetivo para recibir información de recurso de radio desde una RNC de fuente; y un transmisor para transmitir una unidad de datos desde el RNC objetivo hasta una terminal de usuario, la unidad de datos incluyendo un número de secuencia de transmisión que sigue consecutivamente un número de secuencia de transmisión de una última unidad de datos transmitida desde el RNC de fuente a la terminal de usuario. 47. - La unidad de transmisión de conformidad con la reivindicación 46, caracterizada además porque comprende: un procesador para cifrar la unidad de datos antes de la transmisión. 48. - La unidad de transmisión de conformidad con la reivindicación 47, caracterizada además porque el procesador cifra la unidad de datos con un mismo parámetro de cifrado que la terminal de usuario usó para descifrar una unidad de datos transmitida desde el RNC de fuente a la terminal de usuario. 49. - La unidad de transmisión de conformidad con la reivindicación 48, caracterizada además porque el mismo parámetro de cifrado incluye el mismo valor de HFN. 50. - La unidad de transmisión de conformidad con la reivindicación 46, caracterizada además porque el RNC objetivo y la terminal de usuario se operan en un modo U . 51. - La unidad de transmisión de conformidad con la reivindicación 46, caracterizada además porque el transmisor transmite la unidad de datos a través de UM DCCH. 52.- La unidad de transmisión de conformidad con la reivindicación 46, caracterizada además porque el transmisor transmite la unidad de datos a través de un portador de radio de servicio (SRB1 ). 53.- La unidad de transmisión de conformidad con la reivindicación 46, caracterizada además porque el transmisor transmite un indicador de inicio de datos junto con la unidad de datos. 54. - La unidad de transmisión de conformidad con la reivindicación 53, caracterizada además porque el indicador de inicio de datos indica que la unidad de datos no se incluye como parte de una SDU previamente transmitida a la terminal de usuario. 55. - Un método para realizar relocalización de SRNS que comprende: recibir en una RNC objetivo un mensaje de ejecución de relocalización de RNSAP a partir de una RNC de fuente, el mensaje incluyendo un parámetro de cifrado de HFN; modificar el parámetro de cifrado de HFN para coincidir con un parámetro de HFN de una UE, el parámetro de UE HFN correspondiendo a una de los usos de UE cuando se recibe un número de secuencia de PDCP fuera de secuencia; cifrar una RLC PDU con base en el parámetro de cifrado de HFN modificado; y transmitir la RLC PDU cifrada desde el RNC objetivo a la UE. 56. - El método de conformidad con la reivindicación 55, caracterizado además porque el RNC objetivo y la UE se operan en un modo UM. 57. - El método de conformidad con la reivindicación 56, caracterizado además porque comprende: transmitir la RLC PDU cifrada a través de un portador de radio de servicio (SRB1 ). 58. - El método de conformidad con la reivindicación 56, caracterizado además porque comprende: transmitir la RLC PDU cifrada a través de UM DCCH. 59. - El método de conformidad con la reivindicación 55, caracterizado además porque el número de secuencia de PDCP fuera de secuencia no sigue consecutivamente un número de secuencia de PDCP de una última RLC PDU transmitida desde el RNC de fuente a la UE. 60. - El método de conformidad con la reivindicación 55, caracterizado además porque el paso de modificación comprende: ajustar un valor del parámetro de cifrado de HFN para igualar un valor del parámetro de UE HFN cuando se recibe el número de secuencia de PDCP fuera de secuencia. 61 - El método de conformidad con la reivindicación 60, caracterizado además porque el paso de ajuste comprende: incrementar el parámetro de cifrado de HFN para igualar un valor incrementado del parámetro de UE HFN. 62.- El método de conformidad con la reivindicación 55, caracterizado además porque el paso de transmisión comprende: transmitir un valor de INICIO con la RLC PDU cifrada, el valor de INICIO indicando que la RLC PDU cifrada no se incluye como parte de la SDU previamente transmitida a la UE. 63.- Un método de envío de información en un sistema de comunicación de radio móvil que comprende: recibir información que incluye los números relacionados con un número de secuencia de cifrado y una variable de estado de una entidad de control de enlace de radio de un controlador de red de radio que previamente era un controlador de red de radio de servicio de una terminal; establecer una entidad de control de enlace de radio para enviar información a la terminal; fijar la variable de estado de la entidad de control de enlace de radio sincronizada con la variable de estado recibida; y enviar una unidad de datos de la información empezando con la variable de estado a la terminal. 64. - El método de conformidad con la reivindicación 63, caracterizado además porque comprende: fijar un indicador que indique que una unidad de datos de servicio contiene información que empieza en el principio de la unidad de datos de la entidad de control de enlace de radio. 65. - El método de conformidad con la reivindicación 63, caracterizado además porque una de las variables de estado de una entidad de control de enlace de radio es el número de secuencia de la RLC PDU que ha de ser transmitida la siguiente vez. 66.- El método de conformidad con la reivindicación 65, caracterizado además porque una de las variables de estado de una entidad de control de enlace de radio es el número de secuencia más anterior de la RLC PDU que ha de ser retransmitida. 67. - El método de conformidad con la reivindicación 64, caracterizado además porque comprende: enviar una instrucción para mover una ventana receptora a la terminal. 68. - Un método de envío de información en un sistema de comunicación de radio móvil que comprende: recibir una instrucción para instruir para convertirse en un controlador de red de radio de servicio de una terminal desde una red de núcleo junto con información que contiene números relacionados con un número de secuencia de cifrado; establecer una entidad de control de enlace de radio para señalizar información de control a la terminal; fijar el número de secuencia de cifrado de acuerdo con los números recibidos desde el otro controlador de red de radio; fijar un indicador de longitud que indique que la RLC SDU inicia al principio de una RLC PDU; y transmitir el número de secuencia cifrado y la información cifrada a la terminal a través de una entidad de control de enlace de radio. 69.- Un método para enviar información en un sistema de comunicación de radio móvil que comprende: recibir un mensaje de control de recurso de radio de enlace descendente en un portador de radio de señalización; verificar si un controlador de red de radio de servicio es cambiado; cambiar un valor de número de hipercuadro para otro portador de radio de señalización; y transmitir un mensaje de control de recurso de radio de enlace ascendente cifrado con un número desde el número de hipercuadro cambiado. 70. - El método de conformidad con la reivindicación 69, caracterizado además porque comprende: enviar un valor predeterminado para el número de hipercuadro al controlador de red de radio de servicio; y establecer otros portadores de radio de señalización con el valor predeterminado. 71. - El método de conformidad con la reivindicación 70, caracterizado además porque el valor predeterminado es un valor de inicio del número de hipercuadro. 72. - El método de conformidad con la reivindicación 69, caracterizado además porque el valor del número de hipercuadro cambiado es el valor actual +1. 73. - El método de conformidad con la reivindicación 69, caracterizado además porque el valor del número de hipercuadro cambiado es el valor más largo entre los de enlace ascendente y enlace descendente +1.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR20020008341A KR100765123B1 (ko) | 2002-02-16 | 2002-02-16 | Srns 재할당 방법 |
PCT/KR2003/000285 WO2003069806A1 (en) | 2002-02-16 | 2003-02-10 | Method for relocating srns |
Publications (1)
Publication Number | Publication Date |
---|---|
MXPA04007854A true MXPA04007854A (es) | 2004-10-15 |
Family
ID=19719277
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
MXPA04007854A MXPA04007854A (es) | 2002-02-16 | 2003-02-10 | Metodo para relocalizacion se subsistema de red de radio de servicio. |
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)
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 | 移動体通信システム、基地局及びそれらに用いるhsdpa伝送方法 |
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 | 주식회사 케이티프리텔 | Wcdma 무선망에서의 srns 재배치 제어 방법 및장치 |
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 | 엘지전자 주식회사 | 이동통신 시스템에서 pdcp 계층의 상태보고 전송 방법 및 수신장치 |
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 | イノヴァティヴ ソニック リミテッド | 無線通信システムのpdcp層においてデータを暗号化する方法及び装置 |
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 | 엘지전자 주식회사 | 재전송 데이터를 처리하는 harq 동작 방법 |
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 | 이노베이티브 소닉 리미티드 | Rrc 연결 프로시저를 향상시키기 위한 방법 및 장치 |
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 | ブラックベリー リミテッド | Sriメッセージ伝送に基づいてトリガする状態またはモード遷移 |
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)
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 | 주식회사 하이닉스반도체 | Imt-2000 시스템에서의 핸드오프시 srnc 재할당 방법 |
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 | 삼성전자주식회사 | 비동기 imt-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 |
-
2002
- 2002-02-16 KR KR20020008341A patent/KR100765123B1/ko not_active IP Right Cessation
-
2003
- 2003-02-10 AU AU2003207130A patent/AU2003207130B2/en not_active Expired
- 2003-02-10 RU RU2004127673A patent/RU2287228C2/ru active
- 2003-02-10 MX MXPA04007854A patent/MXPA04007854A/es active IP Right Grant
- 2003-02-10 JP JP2003568802A patent/JP4269161B2/ja not_active Expired - Lifetime
- 2003-02-10 WO PCT/KR2003/000285 patent/WO2003069806A1/en active Application Filing
- 2003-02-10 CN CN038039842A patent/CN1633762B/zh not_active Expired - Lifetime
- 2003-02-13 US US10/365,655 patent/US7356146B2/en active Active
- 2003-02-14 ES ES07021120.6T patent/ES2578260T3/es not_active Expired - Lifetime
- 2003-02-14 ES ES03003405T patent/ES2373710T3/es not_active Expired - Lifetime
- 2003-02-14 EP EP20030003405 patent/EP1337125B1/en not_active Expired - Lifetime
- 2003-02-14 EP EP07021120.6A patent/EP1876855B1/en not_active Expired - Lifetime
- 2003-02-14 GB GB0303459A patent/GB2387510B/en not_active Expired - Lifetime
- 2003-02-14 AT AT03003405T patent/ATE532358T1/de active
- 2003-10-02 UA UA20040706256A patent/UA77049C2/uk unknown
-
2004
- 2004-02-18 HK HK04101138A patent/HK1058590A1/xx not_active IP Right Cessation
- 2004-07-14 ZA ZA2004/05611A patent/ZA200405611B/en unknown
-
2007
- 2007-12-03 US US11/949,518 patent/US7706537B2/en not_active Expired - Lifetime
-
2008
- 2008-05-26 JP JP2008137198A patent/JP4995146B2/ja not_active Expired - Lifetime
-
2010
- 2010-03-22 US US12/728,898 patent/US7889867B2/en not_active Expired - Lifetime
Also Published As
Similar Documents
Publication | Publication Date | Title |
---|---|---|
MXPA04007854A (es) | Metodo para relocalizacion se subsistema de red de radio de servicio. | |
EP1593278B1 (en) | Method for processing security message in mobile communication system | |
US7068636B2 (en) | Method for determining RLC entity re-establishment during SRNS relocation | |
JP4523569B2 (ja) | 情報の暗号化方法およびデータ通信システム | |
EP2208294B1 (en) | Method of repairing a security failure | |
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 | |
KR20080085694A (ko) | 이동통신 시스템에서의 무선 프로토콜 처리방법 및이동통신 송신기 | |
JP5344201B2 (ja) | 通信システム | |
KR20090063274A (ko) | 무선 원격통신에서의 암호화 | |
GB2398974A (en) | Method of Relocating SRNS. |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FG | Grant or registration |