ES2328218T3 - Transferencia de parametros de algoritmo de optimizacion durante el traspaso de una estacion movil entre subsistemas de redes de radiocomunicaciones. - Google Patents
Transferencia de parametros de algoritmo de optimizacion durante el traspaso de una estacion movil entre subsistemas de redes de radiocomunicaciones. Download PDFInfo
- Publication number
- ES2328218T3 ES2328218T3 ES00974716T ES00974716T ES2328218T3 ES 2328218 T3 ES2328218 T3 ES 2328218T3 ES 00974716 T ES00974716 T ES 00974716T ES 00974716 T ES00974716 T ES 00974716T ES 2328218 T3 ES2328218 T3 ES 2328218T3
- Authority
- ES
- Spain
- Prior art keywords
- network
- parameters
- destination
- radiocommunications
- rnc
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000005457 optimization Methods 0.000 title claims abstract description 17
- 238000012546 transfer Methods 0.000 title claims description 44
- VJYFKVYYMZPMAB-UHFFFAOYSA-N ethoprophos Chemical compound CCCSP(=O)(OCC)SCCC VJYFKVYYMZPMAB-UHFFFAOYSA-N 0.000 title 1
- 238000000034 method Methods 0.000 claims description 67
- 230000006835 compression Effects 0.000 claims description 33
- 238000007906 compression Methods 0.000 claims description 33
- 230000005540 biological transmission Effects 0.000 claims description 10
- 230000004044 response Effects 0.000 claims description 7
- 239000000243 solution Substances 0.000 description 15
- 230000008859 change Effects 0.000 description 8
- 230000011664 signaling Effects 0.000 description 8
- 101150081027 RNC1 gene Proteins 0.000 description 7
- 101100426111 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) TRM2 gene Proteins 0.000 description 7
- 101150015070 rnc2 gene Proteins 0.000 description 7
- 239000002585 base Substances 0.000 description 4
- 230000002457 bidirectional effect Effects 0.000 description 4
- 238000004891 communication Methods 0.000 description 4
- 101100078001 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) MSC2 gene Proteins 0.000 description 3
- 238000013459 approach Methods 0.000 description 3
- 239000000969 carrier Substances 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000003780 insertion Methods 0.000 description 3
- 230000037431 insertion Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012790 confirmation Methods 0.000 description 2
- 230000006837 decompression Effects 0.000 description 2
- 230000001934 delay Effects 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 101150117600 msc1 gene Proteins 0.000 description 2
- 238000002360 preparation method Methods 0.000 description 2
- 238000000926 separation method Methods 0.000 description 2
- CSRZQMIRAZTJOY-UHFFFAOYSA-N trimethylsilyl iodide Substances C[Si](C)(C)I CSRZQMIRAZTJOY-UHFFFAOYSA-N 0.000 description 2
- IESVDEZGAHUQJU-ZLBXKVHBSA-N 1-hexadecanoyl-2-(4Z,7Z,10Z,13Z,16Z,19Z-docosahexaenoyl)-sn-glycero-3-phosphocholine Chemical compound CCCCCCCCCCCCCCCC(=O)OC[C@H](COP([O-])(=O)OCC[N+](C)(C)C)OC(=O)CC\C=C/C\C=C/C\C=C/C\C=C/C\C=C/C\C=C/CC IESVDEZGAHUQJU-ZLBXKVHBSA-N 0.000 description 1
- 101000711744 Homo sapiens Non-secretory ribonuclease Proteins 0.000 description 1
- 101000667595 Homo sapiens Ribonuclease pancreatic Proteins 0.000 description 1
- 102100034217 Non-secretory ribonuclease Human genes 0.000 description 1
- 102100039832 Ribonuclease pancreatic Human genes 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 238000007792 addition Methods 0.000 description 1
- 239000003637 basic solution Substances 0.000 description 1
- 239000000872 buffer Substances 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- TXFOLHZMICYNRM-UHFFFAOYSA-N dichlorophosphoryloxybenzene Chemical compound ClP(Cl)(=O)OC1=CC=CC=C1 TXFOLHZMICYNRM-UHFFFAOYSA-N 0.000 description 1
- 230000004069 differentiation Effects 0.000 description 1
- 230000008034 disappearance Effects 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 230000008030 elimination Effects 0.000 description 1
- 238000003379 elimination reaction Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000005562 fading Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000005641 tunneling Effects 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
Classifications
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Método de negociación de parámetros para compresión de encabezamientos de un algoritmo de optimización durante un traspaso de una conexión de una estación móvil entre subsistemas de redes de radiocomunicaciones, comprendiendo el método las etapas en las que: se señaliza, desde un subsistema de red de radiocomunicaciones de origen a una red central o a un subsistema de red de radiocomunicaciones de destino, que se requiere dicho traspaso; se señaliza, desde la red central o desde el subsistema de red de radiocomunicaciones de destino al subsistema de red de radiocomunicaciones de origen, que se va a poner en marcha dicho traspaso; y se transmiten dichos parámetros desde dicho subsistema de red de radiocomunicaciones de origen hacia dicho subsistema de red de radiocomunicaciones de destino directamente o a través de la red central sin ninguna necesidad de renegociar dichos parámetros a través de una interfaz aérea entre dicha estación móvil y dicho subsistema de red de radiocomunicaciones de destino.
Description
Transferencia de parámetros de un algoritmo de
optimización durante el traspaso de una estación móvil entre
subsistemas de redes de radiocomunicaciones.
Sistemas celulares por paquetes de 2ª y 3ª
generación.
En la arquitectura de las redes del Sistema
Global para Telecomunicaciones Móviles/Servicio General de
Radiocomunicaciones por Paquetes (GSM/GPRS), tal como se muestra en
la Fig. 13, existen pilas de protocolos de datos conocidas,
asociadas a los diversos elementos de la arquitectura, incluyendo la
estación móvil (MS), un subsistema de estaciones base (BSS) que
incluye una Estación Transceptora Base (BTS) y un Controlador de
Estaciones Base (BSC), un nodo de soporte de servicio GPRS (SGSN) y
un nodo de soporte de pasarela GPRS (GGSN). La MS y el SGSN
comparten en el plano del usuario capas del protocolo de
convergencia dependiente de la subred (SNDCP) y del control de
enlace lógico (LLC) entre entidades pares.
Una de las negociaciones GPRS típicas que se
requiere entre entidades pares en la estación móvil y en algunos de
los dispositivos de la red fija es la negociación de
identificaciones de intercambio o XID, en la que se llega a un
acuerdo sobre los parámetros denominados L3CE (entidad de
compatibilidad de la capa 3).
La arquitectura de la red por paquetes UMTS es
muy similar al GPRS. No obstante, se ha cambiado la denominación de
algunos elementos e interfaces con respecto al GPRS. Mientras la
Fig. 13 muestra la arquitectura de la red GPRS, la Fig. 14 muestra
la arquitectura de la red por paquetes UMTS.
La red por paquetes UMTS consta de los
siguientes elementos de red:
Nodo B: se corresponde con la Estación
Transceptora Base (BTS) del GSM.
RNC (Controlador de Red de Radiocomunicaciones):
se corresponde con el Controlador de Estaciones Base (BSC) del
GSM.
SGSN 3G: la versión de 3ª Generación del Nodo de
Soporte de Servicio GPRS (SGSN) del GSM/GPRS.
GGSN 3G: la versión de 3ª Generación del Nodo de
Soporte de Pasarela GPRS (GGSN).
HLR: el Registro de Posiciones Base (HLR) GSM
con algunas actualizaciones.
Tal como se muestra en la Fig. 14, el Nodo B y
el RNC comprenden la parte RAN de la red UMTS. La RAN se corresponde
con el BSS del GSM. La responsabilidad de la RAN es la
administración de todas las funciones específicas de las
radiocomunicaciones, por ejemplo, el cifrado de canales de
radiocomunicaciones, el control de potencia, el establecimiento y
la liberación de conexiones de portadores de radiocomunicaciones. La
separación básica entre los elementos consiste en que el Nodo B
administra las funciones de la capa física y el RNC administra las
funciones de gestión. No obstante, en último término la separación
podría resultar ser ligeramente diferente a la del
GSM/GPRS.
GSM/GPRS.
La diferencia más grande en la arquitectura es
la interfaz nueva, Iur, dentro de la RAN. La misma reside entre
controladores RNC. El UMTS introduce un nuevo concepto denominado
macrodiversidad. En una situación de macrodiversidad, se envían
datos a través de múltiples Nodo B. Como las señales se transfieren
pasando por múltiples rutas a través de la interfaz aérea y se
combinan, por ejemplo, en la MS y el RNC, el efecto de
desvanecimiento resulta menos dañino y por lo tanto se pueden usar
niveles de potencia menores. No obstante, dichos Nodos B pueden
pertenecer al área de dos o más RNC diferentes, de manera que se
requiere la interfaz, es decir, la interfaz Iur entre controladores
RNC. En esta situación, tal como se muestra a la derecha en la Fig.
15, el RNC se puede encontrar en dos funciones lógicas. En términos
lógicos el RNC puede ser:
o bien un RNC de deriva (DRNC),
o bien un RNC de servicio (SRNC).
\vskip1.000000\baselineskip
El punto de terminación concreto de la interfaz
Iu se encuentra en el SRNC. La interfaz Iu mostrada en la Fig. 14
conecta la Red de Acceso de Radiocomunicaciones (RAN) y la Red
Central (CN) para servicios por conmutación de paquetes o por
conmutación de circuitos. El SRNC controla la transferencia de
información y solicita recursos de radiocomunicaciones de
controladores DRNC adecuados. El DRNC únicamente retransmite
información entre la MS y el SRNC.
La parte de la Red Central (CN) del lado por
conmutación de paquetes consta de elementos SGSN 3G, GGSN 3G y HLR,
tal como se muestra en la Fig. 14. La Red Central (CN) por Paquetes
incluye además la red troncal basada en IP. La red troncal conecta
entre sí elementos de la red central, por ejemplo, el SGSN 3G y el
GGSN 3G.
El SGSN 3G participa en el encaminamiento de
paquetes de usuario así como en funciones de gestión de movilidad y
de sesiones. La capa de Gestión de Movilidad (MM) sabe "quién eres
(seguridad) y en dónde estás (movilidad)". La capa de Gestión de
Sesiones (SM) controla las conexiones de usuario, es decir, las
sesiones.
El GGSN 3G mantiene la información de ubicación
del SGSN 3G, el cual presta servicio a la estación móvil a la que
va dirigido un paquete. La función principal del GGSN 3G es realizar
funciones de interfuncionamiento entre la red UMTS y la red de
datos externa, por ejemplo, Internet. Estas funciones de
interfuncionamiento incluyen, por ejemplo, el establecimiento de
correspondencias de la QoS externa con una QoS UMTS comparable.
El HLR almacena los datos de abonado y contiene
la información sobre a qué SGSN 3G está conectado el usuario. Los
datos de abonado incluyen, entre otros elementos, atributos QoS
predefinidos para las conexiones de usuario.
La pila de protocolos de datos por paquetes UMTS
presenta algunas modificaciones importantes en comparación con el
GPRS, debido en parte a la nueva tecnología de las interfaces de
radiocomunicaciones (WCDMA) y en parte a unos requisitos QoS mucho
mayores.
Uno de los cambios más importantes es que se ha
eliminado la capa de Control de Enlace Lógico (LLC) del ESM/GPRS
por debajo de la Entidad de Compatibilidad de la Capa 3 (L3CE). La
L3CE se corresponde con el Protocolo de Convergencia Dependiente de
la SubRed (SNDCP) del GPRS. Las funciones principales del protocolo
LLC han sido:
el control del flujo entre la MS y la red
central,
el cifrado,
la transferencia de mensajes de
señalización,
el multiplexado de QoS diferentes y
la retransmisión entre la MS y la red
central.
\vskip1.000000\baselineskip
En el UMTS, el LLC no es necesario por las
siguientes razones: 1) se ha decidido que el cifrado tenga lugar en
capas inferiores, dentro de la RAN. 2) La transferencia de mensajes
de señalización no hace uso de protocolos del plano de usuario, ya
que se dispone de protocolos independientes para transferir mensajes
de señalización y por lo tanto la diferenciación entre el plano de
usuario y el plano de control es más clara que en el GPRS.
En la interfaz de radiocomunicaciones UMTS, cada
portador de radiocomunicaciones tendrá su propia entidad de Control
del Enlace de Radiocomunicaciones (RLC). Mediante la aplicación de
este planteamiento, el aprovisionamiento de la QoS resulta más
eficaz. El multiplexado asociado a la QoS será una tarea de la capa
de Control de Acceso al Medio (MAC) y la Capa 1 (L1) y por lo tanto
el LLC no tendrá ningún cometido en el multiplexado de la QoS en el
UMTS. La retransmisión entre la MS y la red central no se puede
justificar de forma sencilla. La fuente principal de los errores es
la interfaz de radiocomunicaciones, y el RLC tiene la
responsabilidad de corregir dichos errores.
No obstante, la eliminación del LLC provocará
una falta de control de flujo entre la MS y la red central. El
control del flujo en el enlace ascendente no constituye un problema,
ya que la interfaz de radiocomunicaciones será el cuello de botella
y el control del flujo del RLC se ocupa de ello. En el enlace
descendente, el RLC administrará la parte RNC-MS.
Entre el RNC y la red central no existe ningún control de flujo. Sin
embargo, esta situación no es mucho peor que la correspondiente al
GPRS, ya que el GPRS no dispone de ningún control de flujo dentro
de la red central (entre el GGSN y el SGSN).
Una transferencia adecuada de datos entre el
GGSN 3G y el RNC se basa en memorias intermedias suficientemente
grandes, una supervisión del tráfico en el GGSN 3G y un control del
flujo de extremo a extremo, por ejemplo, el Protocolo de Control de
Transmisión (TCP). En general, la eliminación del LLC racionaliza la
pila de protocolos, facilita la consecución de velocidades de datos
mayores y reduce el poder de procesado requerido.
Se está revisando la ubicación del homólogo UMTS
de la L3CE (SNDCP en el GPRS) denominado Protocolo de Convergencia
de Datos por Paquetes (PDCP). A diferencia del GPRS, la capa PDCP se
encuentra ubicada en el RNC en lugar del SGSN. El protocolo, entre
otros aspectos, se ocupa de la optimización, por ejemplo, mediante
la compresión de encabezamientos, lo cual constituye una forma de
algoritmo de optimización. Algunos algoritmos de compresión de
encabezamientos se basan en el principio operativo de que la
desaparición de unos pocos paquetes puede provocar una pérdida
adicional no deseable de paquetes debido al propio algoritmo. Esta
situación deteriora la transferencia por paquetes ya que es
necesario realizar más retransmisiones. Situándolo en el RNC, el
tiempo de retransmisión es corto y se puede evitar la retransmisión
al nivel TCP (gracias a los temporizadores TCP).
Los protocolos de la capa de red están
destinados a disponer de la capacidad de poder funcionar sobre
servicios obtenidos a partir de una amplia variedad de subredes y
enlaces de datos. El PDCP soporta varios protocolos de la capa de
red proporcionando transparencia en los protocolos para los usuarios
del servicio. Debería resultar posible introducir protocolos nuevos
de la capa de red para ser transferidos a través del PDCP sin
realizar ningún cambio en otros protocolos UMTS. Por esta razón,
todas las funciones relacionadas con la transferencia de Unidades
de Datos de Protocolos de la Capa de Red (Unidades PDU N) se llevan
a cabo de una forma transparente por parte de las entidades de red.
Otro de los requisitos para el PDCP es proporcionar funciones que
mejoren la eficacia de los datos y de los canales. Esta opción se
consigue mediante un tipo diferente de algoritmos o métodos de
optimización, por ejemplo, la antes mencionada compresión de
encabezamientos.
El UMTS (Sistema de Telecomunicaciones Móviles
Universales), tal como se muestra en la Fig. 14, utiliza estructuras
de protocolos y disposiciones de negociación similares para la
comunicación entre estaciones móviles, Controladores de Redes de
Radiocomunicaciones (controladores RNC) y nodos de servicio de redes
por conmutación de paquetes, con algunas modificaciones. La
negociación de Identificaciones de Intercambio (XID) la lleva a cabo
el PDCP aunque se denominan negociación de parámetros PDCP y se
puede considerar en general como una transferencia de parámetros de
un algoritmo de optimización.
En cualquiera de los casos, los parámetros
negociados harán referencia a los parámetros de dicho algoritmo de
optimización, por ejemplo, al uso de compresión de encabezamientos y
datos. El método GSM/GPRS para disponer una negociación XID
consiste en insertar los parámetros propuestos en ciertos mensajes
en una capa de protocolo LLC y en usar mensajes de respuesta
correspondientes al nivel LLC bien para acusar el recibo de o bien
para rechazar los parámetros SNDCP propuestos.
La negociación XID se realiza habitualmente
cuando se inicializan el SNDCP y el LLC en el GPRS (los valores
para los parámetros XID ya no son válidos). Esta inicialización se
realiza, por ejemplo, cuando se pone en marcha la MS o cuando
cambia la ubicación de los protocolos del lado de la red en un
traspaso.
El problema principal del método de negociación
XID propuesto en la actualidad para el UMTS es que la ubicación del
PDCP es diferente con respecto a la ubicación del protocolo SNDCP y
el LLC. El PDCP se sitúa en la red de acceso de radiocomunicaciones
mientras que los protocolos GPRS comparables se sitúan en redes
centrales. Esto significa que la ubicación del PDCP cambia con
bastante más frecuencia que las ubicaciones del SNDCP y el LLC.
Como los mensajes XID pueden ser relativamente grandes, esta
situación añade a la interfaz aérea en el UMTS mucha más tara que
en el GPRS.
Otro de los problemas es que el UMTS dispone
también de conexiones por paquetes de tiempo real. Esto significa
que las negociaciones tales como la XID deberían ser lo más rápidas
posibles, ya que de otro modo esta situación puede provocar
retardos o por lo menos una tara mayor en la interfaz aérea (la
compresión de encabezamientos no se puede usar después de un
traspaso hasta que se haya realizado satisfactoriamente la
negociación XID).
El documento WO 00/36860 A, el cual se ha
publicado posteriormente y está subordinado al artículo 54(3)
EPC, da a conocer un método para controlar una conexión con una
estación móvil. De forma más detallada, este documento trata sobre
parámetros de cifrado que se usan para evitar escuchas clandestinas
y fraudes.
El objetivo de la invención es proporcionar un
UMTS mejorado así como métodos de negociación GSM/GPRS.
Este objetivo se alcanza con un método según se
expone en la reivindicación 1 o alternativamente con un sistema de
telecomunicaciones móviles según se expone en la reivindicación 3 o
con un elemento de red según se expone en la reivindicación 15.
Esta invención mejora cualquier negociación, tal
como una negociación de parámetros de un algoritmo de optimización,
por ejemplo, una negociación XID, reduciendo la tara que se produce
a través de la interfaz aérea y consiguiendo que el procedimiento
de negociación sea más rápido.
La idea básica de la invención es que durante un
traspaso, se transfieren, desde la entidad antigua a la entidad
nueva en el lado de la red, parámetros tales como el XID, que
contiene información de parámetros sobre métodos de optimización a
soportar. Si los parámetros resultaran adecuados en la entidad
nueva, no es necesaria la negociación concreta entre la MS y la
red, ahorrando de este modo recursos en la interfaz aérea. Este
método es también considerablemente más rápido que, por ejemplo, la
negociación XID normal.
A partir de la exposición anterior, se observará
que la presente invención realmente economiza recursos de la
interfaz aérea y consigue que cualquier tipo de negociación resulte
más rápida, incluyendo la negociación de parámetros referentes a
métodos de optimización tales como el XID, lo cual resulta ventajoso
para conexiones de tiempo
real.
real.
En las reivindicaciones subordinadas se exponen
otras variantes ventajosas de la invención.
Estos y otros objetivos, características y
ventajas de la presente invención se pondrán más claramente de
manifiesto considerando la descripción detallada de una forma de
realización de la misma en su mejor variante, según se ilustra en
los dibujos adjuntos.
La Fig. 1 muestra un controlador de red de
radiocomunicaciones (RNC) de origen que traslada parámetros XID ya
negociados hacia un RNC de destino durante un traspaso, según la
presente invención.
La Fig. 2 muestra un procedimiento simplificado
de reubicación de un SRNS según la presente invención.
La Fig. 3 muestra un MSC en conexión con la
red.
La Fig. 4 muestra la inicialización del MSC.
La Fig. 5 muestra la reubicación del SRNS del
MSC.
La Fig. 6 muestra también la reubicación del
SRNS del MSC.
La Fig. 7 muestra una situación antes de la
reubicación del SRNS y del registro de la ubicación.
La Fig. 8 muestra la situación después de la
reubicación del SRNS y del registro de la ubicación.
La Fig. 9 muestra cómo encajan entre sí las
Figs. 9A y 9B.
Las Figs. 9A y 9B muestran conjuntamente la
secuencia de señalización referente a la transferencia de
información de interfaz para la actualización de la reubicación del
SRNS cuando se cambia el área SGSN dando como resultado un cambio
de ubicación del registro y a continuación un registro de la
ubicación en un área de ubicación nueva.
La Fig. 10 muestra trayectos de datos antes de
que se haya efectuado realmente la reubicación del SRNS.
La Fig. 11 muestra trayectos de datos después de
la actualización del GGSN.
La Fig. 12 muestra trayectos de datos después de
la liberación de recursos en el RNC de origen.
La Fig. 13 muestra la arquitectura de la red
GPRS.
La Fig. 14 muestra la arquitectura de la red por
paquetes UMTS.
La Fig. 15 muestra dos RNC lógicos.
La primera negociación XID después de que la MS
se haya conectado a la red es siempre un tipo de negociación XID
GPRS normal, tal como en la técnica anterior. La negociación de
parámetros XID GPRS como parte del protocolo SNDCP se define en TS
101 297 v.6.4.0 (1999-08) (GSM 04.65 versión 6.4.0
Publicación de 1997 (capítulo 6.8)).
De forma similar, durante un traspaso entre
controladores RNC (reubicación del SRNS), según la evolución
propuesta en la actualidad de la plataforma GSM hacia el UMTS, el
punto de control de la transferencia de datos se traslada desde un
RNC de origen (RNC 1) a un RNC de destino (RNC 2) y por lo tanto se
establece una entidad PDCP nueva con el elemento de red RNC de
destino. No obstante, esta entidad PDCP nueva debería negociar
parámetros XID antes de que comience la transferencia de datos
hacia la MS (el PDCP puede transferir datos antes de conocer los
parámetros XID negociados, aunque en este caso únicamente se le
permite usar valores por defecto de parámetros XID -> no se
permite ninguna optimización, por ejemplo, la compresión de
encabezamientos).
La solución básica de la técnica anterior (como
en el GPRS) sigue siendo que el RNC de destino realice una
negociación XID normal entre él mismo y la MS y que después de esto
dé inicio a la transferencia de datos.
Una solución más ventajosa según la presente
invención, y tal como se ilustra en la Fig. 1, es que el RNC de
origen 16 (RNC 1) traslade los parámetros XID ya negociados hacia el
RNC de destino 20 (RNC 2) durante el traspaso, es decir,
reubicación del SRNS directamente o a través del SGSN 26 (ver 3G TS
23.121 v3.0.0 - capítulo 4.3.12.2.3).
La Fig. 1 muestra un par de subsistemas de red
de radiocomunicaciones 11, 12 conectados a la red central 14 a
través de una interfaz Iu. El sistema de red de radiocomunicaciones
11 consta de un controlador de red de radiocomunicaciones 16 y de
una o más entidades abstractas 18, a las cuales se les puede
denominar Nodo B, que se corresponde con el Subsistema de
Transceptores Base del GSM. Las entidades del Nodo B están
conectadas al RNC a través de una interfaz Iub. Un Nodo B puede
soportar un funcionamiento en modo FDD, en modo TDD o en modo dual.
El RNC es responsable de decisiones de traspasos que requieren una
señalización con la estación móvil 10 a través de una interfaz Uu.
El RNC comprende una función de combinación/división para soportar
la macrodiversidad entre diferentes Nodos B. El Nodo B puede
comprender una función opcional de combinación/división para
soportar la macrodiversidad dentro de un Nodo B. Los RNC 16, 20 de
los subsistemas de red de radiocomunicaciones 11, 12 se pueden
interconectar entre sí a través de una interfaz Iur, tal como ya se
ha descrito previamente en relación con la Fig. 14.
Cada RNC es responsable de los recursos de su
conjunto de células. Para cada conexión entre un equipo de usuario,
tal como la estación móvil MS 10 de la Fig. 1, y la arquitectura de
acceso/central ilustrada, uno de los RNC es el RNC de servicio. En
la Fig. 1, el RNC1 16 es inicialmente el RNC de servicio. El RNC2 20
actúa como RNC de deriva (ver también Fig. 15) y soporta al RNC1 16
de servicio proporcionando recursos de radiocomunicaciones para un
posible traspaso. Al producirse un traspaso de este tipo, tal como
se ha sugerido anteriormente, durante el traspaso entre
controladores RNC, el punto de control de transferencia de datos se
traslada desde el RNC1 16 al RNC2 20 para establecer una entidad
PDCP nueva en el RNC2 20 de destino. Según la técnica anterior,
esta entidad PDCP nueva debería negociar en primer lugar los
parámetros PDCP, antes de comenzar la transferencia de datos hacia
la MS, a no ser que desee únicamente usar los valores por defecto,
es decir, sin optimizaciones.
Según la presente invención, en lugar de
renegociar nuevamente cada vez, por ejemplo, los parámetros PDCP,
tal como en la renegociación de los parámetros del algoritmo de
optimización, el RNC1 16 transfiere los parámetros PDPC ya
negociados hacia el RNC2 20, tal como se indica en una línea 24,
pudiendo tener lugar dicha transferencia a través de la interfaz
Iur o a través de la red central 14, por ejemplo, por medio de un
nodo de soporte de servicio GPRS (SGSN) 26.
La Fig. 2 muestra una forma de realización que
representa un procedimiento simplificado de reubicación del SRNC en
el que en la red central se ven implicados dos SGSN. Una de las
soluciones posibles para la transferencia de parámetros PDCP es el
uso de mensajes de reubicación del SRNC (por ejemplo,
Reubicación_SRNC_Requerida 30, Reenvío_Reubicación_SRNC 32 (por
ejemplo, si el RNS1 y el RNS2 están conectados a SGSN diferentes,
posiblemente hacia otro SGSN 27 no mostrado en la Fig. 1),
Solicitud_Reubicación_SRNC 34 hacia el SRNC de destino 20,
Reubicación_en_Curso 1 36 del SRNC, Respuesta al
Reenvío_Reubicación_SRNC 38, Reubicación_SRNC_en_Curso 2 40,
Ejecución_Reubicación_SRNC 42, Reinicio_RNC 44,
Comienzo_Transmisión_Datos 46, Solicitud_Parámetros_
PDCP (en caso de que fuera necesaria) 48, Respuesta_Parámetros_PDCP (en caso de que fuera necesaria) 50). El formato de los parámetros PDCP puede ser el mismo que en la negociación XID normal de la técnica anterior. Después de que el RNC2 20 de destino reciba estos parámetros PDCP, el mismo comprueba su validez. Si son válidos, el controlador puede usar los parámetros inmediatamente. En cualquier otro caso, el RNC de destino realiza una negociación de tipo XID normal, tal como se sugiere en la Fig. 2 en las etapas 48, 50. Por lo tanto, la negociación PDCP entre la MS y el RNC de destino se realiza únicamente cuando los parámetros PDCP no son válidos en el RNC de destino y por lo tanto se ahorran recursos de la interfaz aérea.
PDCP (en caso de que fuera necesaria) 48, Respuesta_Parámetros_PDCP (en caso de que fuera necesaria) 50). El formato de los parámetros PDCP puede ser el mismo que en la negociación XID normal de la técnica anterior. Después de que el RNC2 20 de destino reciba estos parámetros PDCP, el mismo comprueba su validez. Si son válidos, el controlador puede usar los parámetros inmediatamente. En cualquier otro caso, el RNC de destino realiza una negociación de tipo XID normal, tal como se sugiere en la Fig. 2 en las etapas 48, 50. Por lo tanto, la negociación PDCP entre la MS y el RNC de destino se realiza únicamente cuando los parámetros PDCP no son válidos en el RNC de destino y por lo tanto se ahorran recursos de la interfaz aérea.
No obstante, la MS requiere información sobre la
validez de los parámetros PDCP antes de que pueda enviar datos al
RNC (de otro modo, la MS no puede saber si los parámetros PDCP
resultaron adecuados en el RNC). Existen dos opciones:
Solución preferible: el RNC informa a la MS
sobre la validez del parámetro XID durante/antes del reinicio RLC
en un mensaje independiente, por ejemplo, durante la etapa 44 de la
Fig. 2. Si los parámetros PDCP eran válidos, ambos extremos pueden
usar inmediatamente los mismos parámetros PDCP negociados. Si los
parámetros PDCP no fueran válidos, se realiza la negociación PDCP
después del reinicio, tal como se muestra, por ejemplo, en las
etapas 48, 50. Hasta que se haya completado la negociación PDCP,
todos los paquetes de datos se envían en un modo sin compresión, es
decir, el modo por defecto.
Otra solución: se puede garantizar que la
negociación de parámetros PDCP se puede realizar antes de la
transferencia de datos (preferentemente antes de la etapa 44 de
reinicio del RLC), en caso de que esto sea necesario. (No obstante,
esta opción podría provocar retardos en la reubicación del
SRNC).
Esta recuperación de parámetros PDCP a partir
del RNC de origen, tal como se ha descrito hasta el momento,
presenta un inconveniente. El RNC de destino no puede saber si la MS
puede tratar con parámetros PDCP "mejores", por ejemplo,
métodos de compresión mejores, que los negociados originalmente
entre la MS y el RNC de origen 16 (RNC 1).
Ejemplo:
- La MS puede tratar con los métodos de
compresión de encabezamientos A y B
- El RNC 1 puede tratar con el método de
compresión de encabezamientos A
- El RNC 2 puede tratar con los métodos de
compresión de encabezamientos A y B.
\vskip1.000000\baselineskip
Como la negociación PDCP la realiza
originalmente el RNC 1, únicamente se negocia, para ser usada, la
compresión de encabezamientos A. Después de la reubicación del
SNRC, el RNC 2 comprueba la validez de los parámetros PDCP. En el
ejemplo, los mismos son válidos, ya que el RNC 2 puede tratar con la
compresión de encabezamientos A. El problema es que, en esta
situación, no se realiza la negociación PDCP entre la MS y no se
adopta la compresión de encabezamientos B para su uso. Si la
compresión de encabezamientos B es significativamente mejor, dicha
situación provoca un grado de ineficacia. (La negociación PDCP
normal toma siempre los mejores parámetros XID para su uso).
Este problema se puede evitar, según la también
la invención, con las siguientes mejoras:
En primer lugar, la negociación XID inicial (la
primera negociación XID después de que la MS se conecte a la red)
se inicia siempre desde el lado MS. (Esta situación es la normal en
el GPRS). La MS define y coloca parámetros PDCP adecuados en el
mensaje PDCP. A continuación, la entidad par, es decir, el RNC,
negocia, es decir, selecciona parámetros PDCP apropiados, y fija en
los mismos valores adecuados. Después de esto, el RNC devuelve los
parámetros XID negociados a la MS y dichos parámetros negociados se
adoptan para ser usados.
No obstante, si el RNC, además de los parámetros
PDCP negociados, también almacena los parámetros PDCP "no
usados" o descartados (en el ejemplo, almacena información sobre
la compresión de encabezamientos B), cuando se realiza la
reubicación del SRNC, los parámetros PDCP "no usados" se
recuperan de los medios de almacenamiento y son transferidos
también al RNC de destino. (A continuación se usan los mismos
mensajes de reubicación del SRNC en la transferencia de parámetros
PDCP negociados). Según esta información, el RNC de destino puede
decidir si dichos parámetros XID "no usados" son
"mejores" (en el ejemplo, compresión de encabezamientos B) que
los negociados en ese momento y puede realizar una negociación PDCP
entre MS para adoptar unos parámetros XID nuevos y "mejores"
para ser usados.
A continuación se proporcionarán algunos
ejemplos de la Negociación de parámetros de Compresión de
Encabezamientos (HC) según la invención.
En la Fig. 3 se muestra un ejemplo de
negociación de parámetros de compresión de encabezamientos (HC).
Cuando la Estación Móvil se conecta a los RRC de la red se usa un
mensaje INFORMACIÓN CAPACIDAD UE para informar al SRNC sobre
los métodos de compresión de encabezamientos (HC) que puede usar el
UE y sobre los parámetros de los mismos. Se deja que la red
actualice y se ocupe de esta información.
Después de comparar los parámetros propios de la
red y estos parámetros recibidos, la red toma una decisión sobre el
método HC a usar, teniendo también en cuenta los requisitos QoS. De
este modo, es posible seleccionar el método HC más probable (en
otras palabras, según los requisitos QoS, se puede seleccionar que
el primer método configurado sea un método optimizado o no en
cuanto al tráfico de tiempo real). Después de que la red haya
tomado la decisión, la misma configura su propio compresor, genera
la tabla de valores OPT e impone, usando mensajes RRC
ESTABLECIMIENTO PORTADOR RADIOCOMUNICACIONES (Fig. 4) o
RECONFIGURACIÓN PORTADOR RADIOCOMUNICACIONES (Fig. 5), los
parámetros referentes al algoritmo con el cual está configurado el
compresor en el extremo UE. Al mismo tiempo, la tabla OPT se genera
de manera que se corresponda con la tabla del extremo de la red. El
VE_RRC responde con un mensaje
ESTABLECIMIENTO_PORTADOR_RADIOCOMUNICACIONES_COMPLE-
TO (Fig. 4) al SRNC_RRC o con un mensaje RECONFIGURACIÓN_PORTADOR_ RADIOCOMUNICACIONES_
COMPLETA (Fig. 5) en el caso de una reconfiguración.
TO (Fig. 4) al SRNC_RRC o con un mensaje RECONFIGURACIÓN_PORTADOR_ RADIOCOMUNICACIONES_
COMPLETA (Fig. 5) en el caso de una reconfiguración.
Como la red sabe (Fig. 3) qué algoritmos pueden
usar el UE y la propia red, es posible configurar un compresor
nuevo en el caso de que se reconozcan otros tipos de paquetes
(diferentes con respecto a los soportados por el compresor en
curso) y de que la compresión de los mismos sea soportada por la red
y el UE. En tal caso, se configurarán inmediatamente compresores
nuevos en ambos extremos. Si la notificación se encuentra en el
extremo UE, los mismos se envían en primer lugar al RNC sin
comprimir y después de que el RNC perciba la situación, el mismo
configura los compresores en ambos extremos. El compresor nuevo en
el extremo UE se configura usando un mensaje RECONFIGURACIÓN
PORTADOR RADIOCOMUNICACIONES (Fig. 5) que contiene la
información que se envía cuando se está configurando el método
nuevo.
Como la red mantiene la información de todos los
métodos posibles para su uso tanto en el UE como en la red y como
únicamente se está configurando el método más probable, es posible
dejar que los compresores de otros métodos se configuren más tarde
en caso de que sea necesario.
En el caso de una reubicación de un SRNS, tal
como se detalla en la Fig. 6, después del último mensaje
Ejecución_reubicación_SRNC, se envía un mensaje nuevo
RECONFIGURACIÓN PORTADOR RADIOCOMUNICACIONES RNC (Fig. 5), en
el que si el método cambia se comunican parámetros HC nuevos. En el
caso de que el método no cambie, se comunican únicamente parámetros
antiguos y se transmite información sobre la reinicialización
(si/no) del compresor. Si no se produce ninguna reinicialización,
en ese caso la compresión/descompresión continúa tal como se
producía en el RNC antiguo.
\newpage
Nuevamente, cuando la Estación Móvil se conecta
a los RRC de la red con el mensaje INFORMACIÓN CAPACIDAD UE
de la Fig. 3, se informa al SRNC_RNC sobre los métodos deseados de
compresión de encabezamientos (HC) que puede usar el UE y sobre los
parámetros relacionados. Se deja que la red actualice y se ocupe de
esta
información.
información.
La red selecciona los métodos que pueden ser
soportados basándose en sus métodos propios soportados así como en
los correspondientes al UE. Después de esto, la red podría enviar
los parámetros de todos los métodos soportados al mismo tiempo que
un mensaje, al UE. Esto significaría que tanto la red como el UE
conocerían qué métodos se pueden soportar. En este caso también se
genera la tabla OPT que indica tipos diferentes de paquetes de
métodos diferentes de manera que la misma sea similar en ambos
extremos. Esta transferencia de información se puede llevar a cabo
usando los mensajes ESTABLECIMIENTO PORTADOR
RADIOCOMUNICACIONES del RRC, tal como se muestra en la Fig. 4,
o RECONFIGURACIÓN PORTADOR RADIOCOMUNICACIONES, tal como se
muestra en la Fig. 5. Al mismo tiempo se informa del método más
probable y el mismo se configura, y se crea el compresor.
En el caso de que el compresor configurado sea,
por ejemplo, TCP/IP, aunque posteriormente se reconozcan paquetes
de tiempo real RTP/UDP/IP, el PDCP reconoce la situación y genera un
compresor nuevo para estos últimos. Se configura este compresor
nuevo RTP/UDP/IP, dentro del compresor se generan los contextos
basados en flujos continuos, y se envían hacia el otro extremo
Encabezamientos Completos (FH) basados en flujos continuos. La capa
de enlace, usando el campo OPT, informa sobre qué método de
compresión se trata en cuestión, e informa también de que está
tratando con los Encabezamientos Completos (FH) de ese método. El
otro extremo percibe la situación, configura el descompresor y
(usando encabezamientos (FH) genera los contextos internos correctos
para los flujos continuos existentes. En esta situación, no es
necesario enviar mensajes RECONFIGURACIÓN PORTADOR
RADIOCOMUNICACIONES. Después de esto, el compresor puede enviar
paquetes comprimidos sin ninguna acción adicional. Esta solución
funciona de forma independiente con respecto al extremo de
transmisión (UE/red).
Otra de las soluciones es que, para todos los
métodos soportados, los compresores propios de cada extremo se
configuren inmediatamente en el inicio, lo cual significa que la
configuración del compresor se realiza solamente una vez. En este
caso, en el interior del compresor se generan únicamente los
contextos propios específicos basados en flujos continuos, y los
Encabezamientos Completos (FH) basados en flujos continuos se
envían a otro extremo. Además si el mismo compresor soporta dos
métodos, la configuración no es necesaria sino que se generan
únicamente los contextos del compresor basados en flujos continuos
propios de este último y los FH se envían a otro extremo.
Nuevamente, en la reubicación del SRNS después
del mensaje Ejecución_reubicación_SRNC, tal como se muestra en la
Fig. 6, se está enviando un mensaje nuevo RECONFIGURACIÓN
PORTADOR RADIOCOMUNICACIONES RNC (Fig. 5), en el que se informa
al UE en el caso de que el método cambie. En el caso de que el
método no cambie, se envía únicamente información sobre la
reinicialización (si/no) del compresor. Si no se produce ninguna
reinicialización, en ese caso la compresión/descompresión continúa
tal como se producía en el RNC antiguo.
\vskip1.000000\baselineskip
También es posible que la red informe al UE
sobre los métodos que soporta cuando se produce la conexión a la
red y, en el caso de una reubicación del SRNS, después del mensaje
Ejecución_reubicación_SRNC. En este caso, el UE inicia la
transmisión de parámetros del compresor usando cierta señalización,
basada en el ESTABLECIMIENTO PORTADOR RADIOCOMUNICACIONES
(Fig. 4) y en la RECONFIGURACIÓN PORTADOR RADIOCOMUNICACIONES
(Fig. 5), y el procedimiento de generación del compresor según el
ejemplo 1 ó 2 con la diferencia de que el UE envía los mensajes de
configuración y la red los recibe.
La solución actual (técnica anterior) en el GPRS
es que la negociación XID se realiza nuevamente cuando cambia la
ubicación del SGSN (traspaso entre nodos SGSN). Esta negociación es
necesaria debido a que los protocolos SNDCP y LLC se sitúan en el
SGSN y los parámetros XID antiguos no son conocidos en el SGSN nuevo
(y además puede que los mismos sean no aplicables). La negociación
XID se realiza para ciertos parámetros (la mayoría, aunque no
todos) LLC y SNDCP, por ejemplo, parámetros de compresión de
encabezamientos.
No obstante, este planteamiento no resulta muy
adecuado para el UMTS.
- En el UMTS, el PDCP se sitúa en el RNC, de
manera que la negociación se deberá realizar con mayor
frecuencia.
- El UMTS dispone también de portadores de
tiempo real para datos por paquetes.
- La negociación debería ser lo más rápida
posible.
Nota: probablemente la negociación de parámetros
PDCP no se denominará negociación XID, simplemente negociación de
parámetros PCDP en el UMTS.
\global\parskip0.930000\baselineskip
Alternativas posibles a la realización de la
negociación PDCP entre el UE y el RNC de destino:
A continuación se describe detalladamente la
reubicación del SRNS. Toda la información necesaria se transfiere
desde el RNC de origen al RNC de destino.
- -
- parámetros PDCP negociados -> RNC de destino, con independencia de que los mismos se consideren OK o no para este último. En caso afirmativo, no es necesaria una negociación nueva y se ahorran recursos y tiempo de la interfaz aérea.
- -
- Información de la capacidad del UE -> esta incluye información de la capacidad PDCP del UE entre otras capacidades. La información de capacidad PDCP puede contener, por ejemplo, la siguiente información: número de versión PDCP y métodos de compresión de encabezamientos soportados y otros parámetros. Esta última opción no es obligatoria.
1) Una de las soluciones consiste en que la red
imponga (protocolo RRC en el RNC) qué parámetros se usan en el UE
(en protocolos diferentes de la capa de radiocomunicaciones, L1,
MAC; RLC, PDCP). Esta no es una negociación bidireccional real como
la negociación XID. No obstante, la red sabrá qué parámetros puede
soportar el UE (ya que la red no puede imponer lo que no puede
soportar el UE). Esta capacidad del UE se puede transferir desde el
SRNC de origen (sugerida) o se puede solicitar desde el UE mediante
la "consulta capacidad UE" (ver especificación RRC - TS 25.331
v1.5.0: Capítulos 8.1.6 y 8.1.7). A continuación, el SRNC de destino
puede negociar (imponer) parámetros nuevos para el UE. La solución
actual (técnica anterior) es que los parámetros se transfieran en
mensajes "Establecimiento/Reconfiguración
Portador/Radiocomunicaciones" (ver TS 25.332: Capítulo 8.2).
Probablemente, los parámetros PDCP reales se deberían denominar
"Info PDCP" tal como la "Info RLC" (ver tabla del
capítulo 10.1.5.4). También son posibles otros mensajes (nuevos o
existentes).
En el caso en el que los parámetros se
consideraran OK en el SRNC de destino:
- -
- Se proporciona una indicación de que los parámetros negociados anteriormente se consideraron OK. Ambos lados de la comunicación usan parámetros antiguos. Esta indicación puede ser un mensaje del nivel RRC, propio de la entidad en cuestión, o parte de un mensaje "Establecimiento/Reconfiguración Portador Radiocomunicaciones". Esta indicación puede ser muy corta (1 bit) para indicar si los parámetros negociados se consideraron o no OK.
En el caso de que los parámetros no se
consideraran OK en el SRNC de destino:
- -
- El RNC de destino impone parámetros nuevos teniendo en cuenta la capacidad del UE. (Negociación normal de parámetros PDCP).
En esta solución, no se produce ahorro de
tiempo, ya que la negociación es unidireccional.
2) En esta solución, la negociación de
parámetros PDCP es bidireccional entre la red (RNC) y el UE. En este
caso, la información sobre la capacidad del UE no es obligatoria
(aunque la misma puede ser de ayuda para el SRNC de destino cuando
negocie parámetros nuevos). Después de que el SRNC reciba los
parámetros a negociar, el mismo comprueba la idoneidad de los
parámetros.
En el caso de que los parámetros se consideren
OK en el SRNC de destino:
- -
- Se proporciona una indicación de que los parámetros negociados anteriormente se consideran OK. Ambos lados de la comunicación usan los parámetros antiguos. Esta indicación puede ser un mensaje del nivel RRC, propio de la entidad en cuestión, o parte de un mensaje "Establecimiento/Reconfiguración Portador Radiocomunicaciones". Esta indicación puede ser muy corta (1 bit) para indicar si los parámetros negociados se consideraron o no OK.
En el caso de que los parámetros no se
consideraran OK en el SRNC de destino:
- -
- El RNC de destino negocia parámetros nuevos. (Negociación de parámetros PDCP bidireccional). El mensaje de la primera dirección (solicitud) puede ser el mismo que en la solución 1) es decir, "Establecimiento/Reconfiguración Portador Radiocomunicaciones", tal como en las Figs. 4 ó 5, y el mensaje de la segunda dirección (respuesta) podría ser "Establecimiento/Reconfiguración Portador Radiocomunicaciones Completo" (ver capítulo 10.1.5.5). También puede que sean posibles mensajes nuevos (propios) para la negociación PDCP en el protocolo RRC.
En esta solución se ahorra tiempo ya que
únicamente es necesario realizar la negociación bidireccional cuando
los parámetros no se consideraron OK.
Nota: en ambas soluciones, se considera que el
RRC realiza la negociación PDCP y después de la negociación (si
fuera necesario) el RRC informa de los parámetros nuevos al PDCP.
Una solución alternativa es que el PDCP realice por sí mismo la
negociación. En ese caso no se usan mensajes RRC, sino que el PDCP
usa sus PDU propias para la negociación. No obstante, los
principios de funcionamiento básicos también son los mismos en este
caso.
\global\parskip1.000000\baselineskip
También se podría usar un planteamiento similar
en versiones futuras del GPRS.
Principios de funcionamiento de la reubicación
del SRNS según la 3G TS 23.121 v 3.1.0 (1999-10) del
Grupo de Especificaciones Técnicas Aspectos de Servicios y
Sistemas; Requisitos de la Arquitectura para la Edición 1999 en la
Sección 4.3.14.2, de acuerdo con las modificaciones según la
presente invención:
Según el Capítulo 4.3.14.2.1 de la 3G TS 23.121,
para llevar a cabo una reubicación del SRNS, el SRNC de origen debe
dar inicio al procedimiento de reubicación del SRNS, ya que no es el
SRNC de destino sino el SRNC de origen el que conoce los servicios
en curso de un usuario. Esta operación se realiza únicamente cuando
este procedimiento presenta el menor efecto negativo sobre el
tráfico del usuario. Los procedimientos de reubicación del SRNC
deben garantizar que existe solamente un RNC del Servicio para un
usuario incluso si este usuario tiene servicios a través de más de
un dominio (IP o ISDN).
El procedimiento de reubicación del SRNS se
divide en dos fases. En la primera fase se reservan recursos en las
interfaces IU nuevas y (si fuera necesario) dentro de la CN.
Únicamente cuando esta primera fase se ha llevado a cabo
satisfactoriamente para todos los dominios en los cuales dispone de
algunos servicios en ese momento el usuario, el SRNC de origen
podrá dar inicio a la segunda fase, es decir, un traspaso de la
función del SRNC al SRNC de destino.
Los procedimientos de señalización que se
muestran posteriormente no representan el conjunto completo de
posibilidades, según la especificación TS 23.121, ni obligan a este
tipo de operación. Debería entenderse según la normativa, que se
debería especificar un conjunto de procedimientos elementales para
cada interfaz, los cuales se pueden combinar de formas diferentes
en una implementación. Por lo tanto, las secuencias ilustrativas
constituyen simplemente ejemplos de una implementación típica. En
estos ejemplos de la norma 3G TS 23.121, MSC representa MSC_3G/VLR
y SGSN representa SGSN_3G.
Este ejemplo muestra la reubicación del SRNS
cuando el RNC de origen y el RNC de destino están conectados a
SGSN_3G diferentes. La Fig. 7 y la Fig. 8 ilustran respectivamente
la situación antes y después de la reubicación y del registro de
ubicación del SRNS. La Fig. 9 ilustra la secuencia de señalización
en la que cada una de las etapas se explica posteriormente.
Tal como se muestra en la Fig. 7, antes de la
reubicación y del registro de la ubicación del SRNS, el UE se
registra en el SGSN1 y en el MSC1. El UE se encuentra en estado MM
de conexión hacia el SGSN1 y en estado MM de reposo (ver Capítulo
4.3 Gestión de Movilidad UMTS (UMM) en la 3G TS 23.121) hacia la
MSC1. El RNC1 está actuando como SRNC y el RNC2 está actuando como
DRNC.
Después de la reubicación y del registro de
ubicación del SRNS tal como se muestra en la Fig. 8, el UE se
registra en el MSC2 y en el SGSN2. El UE se encuentra en estado MM
de conexión hacia el SGSN2 y en estado MM de reposo hacia el MSC2.
El RNC2 está actuando como SRNC.
En la reubicación del SRNS:
El SGSN de origen y de destino intercambian
información al nivel de la CN (marca de clase CN, lista de contextos
PDP establecidos)
El SRNC de origen y de destino intercambian
información al nivel del UTRAN (Marca de clase UTRAN, ...) e
información usada para garantizar que no se pierde ningún paquete
de usuario ni que el mismo se duplica durante el procedimiento de
reubicación del SRNS. Según los aspectos dados a conocer de la
presente invención, esta información al nivel UTRAN incluye también
parámetros PDCP (XID) negociados.
Durante esta fase, según también el capítulo
4.3.14.2.3 de la 3G TS 23.121 v 3.1.0 (1999-10),
tiene lugar la transmisión de paquetes entre el GGSN y el UE a
través del SRNC de origen. Los siguientes párrafos numerados se
corresponden con las etapas numeradas de las Fig. 9A y 9B, las
cuales encajan la una con la otra tal como se muestra en la Fig.
9.
1. La UTRAN (SRNC de origen) toma la decisión de
realizar el procedimiento de reubicación del RNC de Servicio. Esta
opción incluye una decisión sobre en qué RNC (RNC de Destino) se va
a reubicar la funcionalidad del RNC de Servicio. El SRNC de origen
envía al SGSN1 mensajes de Reubicación SRNC Requerida. Este mensaje
incluye parámetros tales como un identificador el RNC de destino y
un campo de información que se trasladará de forma transparente al
RNC de destino. Según la presente invención, esta puede incluir
parámetros PDCP (XID) negociados, capacidad del UE (por ejemplo,
métodos de compresión de encabezamientos soportados por el UE) y
cualquier otro parámetro relacionado.
\global\parskip0.900000\baselineskip
2. Al producirse la recepción del mensaje de
Reubicación SRNC requerida, el SGSN1 determina, a partir de la
información recibida, que la reubicación del SRNC dará como
resultado (por ejemplo, en este caso) un cambio de SGSN.
A continuación, el SGSN enviará una solicitud de
Reenvío de Reubicación del SRNC hacia el SGSN aplicable (por
ejemplo, el SGSN2) incluyendo la información recibida del SRNC de
Origen (ver información anterior de parámetros PDCP (XID) según la
invención) e información necesaria para el cambio de SGSN (por
ejemplo, contexto MM, contexto PDP). La información del contexto
PDP contiene la lista del contexto PDP (incluyendo tipo de PDP, QoS
solicitada/negociada) establecida en ese momento por el UE junto
con la dirección del GGSN asociado. No contiene ninguna información
vinculada con la transmisión de paquetes (números de secuencia) ya
que dicha información se encuentra bajo la responsabilidad de la
UTRAN.
3. El SGSN2 envía al RNC de destino un mensaje
Solicitud Reubicación SRNC. Este mensaje incluye información para
desarrollar el contexto SRNC, enviado de forma transparente desde el
SRNC de Origen (por ejemplo, la ID del UE, el número de nodos CN
conectados, información de capacidad del UE (incluyendo la
transferencia de información de la invención referente a parámetros
PDCP (XID) descrita anteriormente), y directrices para establecer
portadores de transporte del plano de usuario Iu.
Cuando se han establecido los portadores de
transporte del plano de usuario Iu, y el RNC de destino ha
completado su fase de preparación, se envía al SGSN2 el mensaje
Reubicación SRNC en Curso 1, tal como se muestra en las Figs. 9A y
9B. El mensaje Reubicación SRNC en Curso 1 contiene
la(s) dirección(es) IP (posiblemente una dirección
por cada contexto PDP) en la(s) cual(es) desea recibir
estos paquetes el RNC de destino.
4. Cuando se han asignado los recursos de
tráfico entre el RNC de destino y el SGSN2, y el SGSN2 está
preparado para el cambio de SRNC, a continuación se envía desde el
SGSN2 al SGSN1 la Respuesta Reenvío Reubicación SRNC. Este mensaje
indica que se han asignado recursos necesarios para la reubicación
del SRNC: el SGSN2/RNC de destino están preparados para recibir
desde el SRNC de origen, los paquetes de sentido descendente cuyo
recibo no ha sido acusado todavía por el UE. El mensaje
Respuesta Reenvío Reubicación SRNC contiene la(s)
dirección(es) IP que se proporcionó(proporcionaron) en el
mensaje Reubicación SRNC en Curso 1.
5. Cuando en el SGSN1 se ha recibido la
Respuesta Reenvío Reubicación SRNC, el SGSN1 indica que se
completado la fase de preparación en el lado del dominio PS de la
CN para la reubicación del SRNC enviando al RNC de Origen el
mensaje Reubicación SRNC en Curso 2. Este mensaje contiene
la(s) dirección(es) IP (posiblemente una dirección
por cada contexto PDP) a la(s) cual(es) enviar los
paquetes de sentido descendente cuyo recibo no ha sido acusado
todavía por el UE.
6. Cuando el RNC de origen ha recibido el
mensaje Reubicación SRNC en Curso 2, el RNC de origen envía al RNC
de destino un mensaje Ejecución Reubicación SRNC (lista de (SNU,
UP_RLC_ACK, SND)). El SND es el número de secuencia GTP
correspondiente al siguiente paquete de enlace descendente recibido
desde el GGSN. El SNU es el número de secuencia GTP correspondiente
al siguiente paquete de enlace ascendente que se va a tunelizar
hacia el GGSN. UP_RLC_ACK contiene los acuses de recibo
correspondientes a una PDU de sentido ascendente recibida por el
SRNC de origen sobre cada una de las conexiones RLC usadas por el UE
(es decir, la Variable de Estado en Recepción V(R) para
todos los SAPI RLC en el modo con acuse de recibo. El SRNC de origen
pone en marcha un temporizador T3-TÚNEL, detiene el
intercambio de los paquetes con el UE (punto (a)), y da inicio a la
tunelización de los paquetes de sentido descendente almacenados
temporalmente hacia el SRNC de destino. El RNC de destino ejecuta
una conmutación para todos los portadores en el instante de tiempo
adecuado que se produzca antes. En esta fase, según la presente
invención, si fuera necesario se negociarán parámetros PDCP nuevos.
Ver la descripción anterior en relación con posibles alternativas
para la negociación PDCP entre el UE y el RNC.
7. El RNC de destino comienza a actuar como un
SRNC y las etapas restantes 7 a 14 del Capítulo 4.3.14.2.3 de la 3G
TS 23.121 v 3.1.0 (1999-10) siguen siendo las mismas
y no se ven afectadas por la presente invención. El SRNC de
destino:
- (a)
- Reinicia las conexiones RLC. Esto incluye el intercambio entre el SRNC de destino y el UE, del UP_RLC_ Ack y el DOWN_RLC_ACK. El DOWN_RLC_ACK confirma todos los paquetes destinados al móvil que se han transferido satisfactoriamente antes del inicio del procedimiento de reubicación. Si el DOWN_RLC_ ACK confirma la recepción de paquetes que se reenviaron desde el SRNC de origen, en ese caso el SRNC de destino descartará dichos paquetes. El UP_RLC_Ack confirma todos los paquetes originados en el móvil que se transfirieron satisfactoriamente antes del inicio del procedimiento de reubicación. A partir de este momento se puede reiniciar el intercambio de los paquetes con el UE (punto(b)).
- (b)
- Envía una Información del Sistema MM Nueva al UE indicando, por ejemplo, un Área de Encaminamiento y un Área de Ubicación pertinentes. Una RAI nueva activa un procedimiento de actualización del área de encaminamiento. A continuación, también se puede enviar al UE una información RRC adicional, por ejemplo, una identidad RNTI nueva. Esta opción puede activar un procedimiento de actualización de ubicación (ver posteriormente la etapa 12).
\global\parskip1.000000\baselineskip
8. Inmediatamente después de una conmutación
satisfactoria en el RNC, el RNC de destino (= SRNC) envía al SGSN2
un mensaje Detección Reubicación SRNC. Después de enviar fuera la
Información del Sistema MM Nueva, el RNC de destino envía al SGSN2
un mensaje Reubicación SRNC Completa.
9. El UE envía al SGSN2 una solicitud de
actualización de área de Encaminamiento (RAI antigua;
P-TMSI antigua; firma PTMSI antigua, tipo
Actualización) cuando la Información del Sistema MM Nueva incluya
una RAI nueva.
10. Al producirse la recepción de la solicitud
RAU, el SGSN2 actualiza el(los) GGSN con una Solicitud
Actualización Contexto PDP que incluye la dirección SGSN nueva. A
continuación, el(los) GGSN actualiza(n) el contexto
PDP y devuelve una Respuesta Actualización Contexto PDP. El SGSN
envía hacia el SGSN1 una Reubicación SRNC Completa.
11. En la recepción de la Reubicación SRNC
Completa, el SGSN1 enviará una indicación de liberación hacia el
RNC de Origen. Todos los recursos asignados a este UE por el RNC de
origen se liberan únicamente cuando se ha recibido este mensaje y
se ha producido la expiración del temporizador
T3-TÚNEL. Antes de que se produzca la expiración
del temporizador T3-TÚNEL, todos los paquetes de
sentido descendente recibidos desde el GGSN se envían hacia el SRNC
de destino.
12. El SGSN2 informa al HLR sobre el cambio de
SGSN enviando una Actualización de ubicación GPRS (IMSI, dirección
SGSN nueva, etcétera) al HLR. El HLR cancela el contexto en el SGSN
antiguo, SGSN1, enviando una Cancelación Ubicación (IMSI). El SGSN1
elimina el contexto y proporciona una confirmación con un Ack
Cancelación Ubicación. El HLR envía al SGSN2 un Inserción datos
abonado (IMSI, datos de suscripción). El SGSN2 proporciona una
confirmación con un Ack Inserción Datos Abonado. El HLR confirma la
Actualización de la ubicación GPRS enviando al SGSN2 un Ack
Actualización Ubicación GPRS.
13. En la recepción del Inserción datos abonados
desde el HLR, el SGSN2 iniciará la actualización de información MM
almacenada en el UE. Esto se realiza enviando al UE una Orden de
Actualización del Área de Encaminamiento iniciada por la red. Este
mensaje incluirá una RAI nueva, y posiblemente también una
P-TMSI nueva. Cuando el UE ha realizado las
actualizaciones necesarias, responde con una Actualización del Área
de Encaminamiento iniciada por la Red Completa.
14. Cuando se recibe una información del sistema
MM nueva que indica un Área de Ubicación nueva, el UE, en este
caso, iniciará un procedimiento de actualización de Área de
Ubicación hacia el MSC2. Esto implica que la actualización del Área
de Ubicación se realizará en paralelo con las actividades antes
indicadas asociadas al lado SGSN de la Red Central.
Antes del punto (a) en la Fig. 9A, la conexión
entre el UE y el GGSN se establece a través del SRNC de Origen y el
SGSN1, tal como se muestra en la Fig. 10 (Fig. 4-28
de la 3G TS 23.121 v 3.1.0).
Después de la transmisión del "ejecución
reubicación SRNS" hacia el SRNC de destino (después del punto (a)
en la Fig. 9A), el RNC de origen no puede intercambiar datos con el
UE debido a que su RLC debería estar congelado después de la
transmisión de los números de secuencia RLC hacia el RNC de destino.
La transferencia de datos no puede tener lugar antes del reinicio
del RLC entre el SRNC de destino y el UE (antes del punto (b) de la
Fig. 9A). Todos los paquetes de sentido descendente recibidos por el
SRNC de destino durante esta fase se almacenan temporalmente hasta
el reinicio del RLC entre el SRNC de destino y el UE.
Después del punto (c), en la Fig. 9A, se
establece la conexión entre el UE y el GGSN a través del RNC de
Destino y el SGSN2.
Antes de la liberación de recursos en el RNC de
origen (antes de la expiración del T3-TÚNEL), el
SRNC de destino puede recibir paquetes de sentido descendente desde
dos trayectos. Los paquetes que quedan en la red troncal se envían
sobre el "Trayecto antiguo" (a través del SGSN1 y el RNC1) y
son reenviados por el RNC1 de origen al SRNC2 de destino mientras
que los paquetes recibidos por el GGSN en su interfaz Gi se envían
sobre el trayecto nuevo (a través del SGSN2) al SRNC2 de
destino.
La Fig. 11 muestra trayectos de datos después de
la actualización del GGSN (después del punto (c) de la Fig.
9A).
La Fig. 12 muestra trayectos de datos después de
la liberación de recursos en el RNC de origen (después de la
respuesta de liberación en la Fig. 9A).
Aunque la invención se mostrado y descrito con
respecto a una forma de realización de la misma en su mejor
variante, los expertos en la materia deberían entender que los
cambios, omisiones y adiciones anteriores y otros diversos
realizados sobre la forma y detalles de la misma se pueden aplicar
sin apartarse por ello del espíritu y del alcance de la
invención.
Claims (15)
1. Método de negociación de parámetros para
compresión de encabezamientos de un algoritmo de optimización
durante un traspaso de una conexión de una estación móvil entre
subsistemas de redes de radiocomunicaciones, comprendiendo el
método las etapas en las que:
se señaliza, desde un subsistema de red de
radiocomunicaciones de origen a una red central o a un subsistema
de red de radiocomunicaciones de destino, que se requiere dicho
traspaso;
se señaliza, desde la red central o desde el
subsistema de red de radiocomunicaciones de destino al subsistema
de red de radiocomunicaciones de origen, que se va a poner en marcha
dicho traspaso; y
se transmiten dichos parámetros desde dicho
subsistema de red de radiocomunicaciones de origen hacia dicho
subsistema de red de radiocomunicaciones de destino directamente o a
través de la red central sin ninguna necesidad de renegociar dichos
parámetros a través de una interfaz aérea entre dicha estación móvil
y dicho subsistema de red de radiocomunicaciones de destino.
2. Método según la reivindicación 1, en el que
durante el establecimiento inicial de dicha conexión entre la
estación móvil y el subsistema de red de radiocomunicaciones de
origen, los parámetros pueden incluir varios conjuntos opcionales
de parámetros, siendo aceptado solamente uno de ellos por el
subsistema de red de radiocomunicaciones de origen, comprendiendo
además dicho método la etapa en la que se almacena la totalidad de
dichos conjuntos opcionales de parámetros en la que dicha etapa de
transmisión de dicho parámetro incluye la transmisión de la
totalidad de dichos conjuntos opcionales de parámetros.
3. Sistema de telecomunicaciones móviles que
incluye una red central (14) conectada (Iu) a diversos subsistemas
de red de radiocomunicaciones (11, 12) interconectados (Iur), para
comunicarse con una estación móvil (10) a través de una interfaz
aérea (Uu), en el que un primero de entre dichos subsistemas de red
de radiocomunicaciones (11) incluye un controlador de red de
radiocomunicaciones de origen (16) para señalizar a dicha red
central o a un controlador de red de radiocomunicaciones de destino
(20) en un segundo de entre dichos subsistemas de red de
radiocomunicaciones (12) que se requiere un traspaso, en el que en
respuesta a esto último dicha red central o dicho subsistema de red
de radiocomunicaciones de destino señaliza al controlador de red de
radiocomunicaciones de origen que se va a poner en marcha dicho
traspaso, y en el que a continuación se transmiten parámetros de
compresión de encabezamientos de un algoritmo de optimización desde
dicho controlador de red de radiocomunicaciones de origen hacia
dicho controlador de red de radiocomunicaciones de destino
directamente o a través de la red central sin ninguna necesidad de
renegociar dichos parámetros a través de dicha interfaz aérea entre
dicha estación móvil y dicho controlador de red de
radiocomunicaciones de destino.
4. Sistema según la reivindicación 3, en el que
durante una negociación inicial de dichos parámetros entre la
estación móvil y el controlador de red de radiocomunicaciones de
origen, dichos parámetros incluyen varios conjuntos opcionales de
parámetros, siendo aceptado solamente uno de ellos por el
controlador de red de radiocomunicaciones de origen, en el que
dichos varios conjuntos opcionales de parámetros son almacenados por
dicho controlador de red de radiocomunicaciones de origen para su
transmisión hacia dicho controlador de red de radiocomunicaciones
de destino después de que dicho controlador de red de
radiocomunicaciones de origen señalice a dicho controlador de red
de radiocomunicaciones de destino que se va a poner en marcha dicho
traspaso.
5. Método según la reivindicación 1, en el que
dichos parámetros son paquetes del Protocolo de Convergencia de
Datos por Paquetes (PDCP).
6. Sistema según la reivindicación 3, en el que
dichos parámetros son paquetes del Protocolo de Convergencia de
Datos por Paquetes (PDCP).
7. Método según la reivindicación 1, que
comprende además la etapa en la que se comprueba si dichos
parámetros recibidos desde dicho subsistema de red de
radiocomunicaciones de origen son o no válidos.
8. Sistema según la reivindicación 3, en el que
se comprueba la validez o no validez de los parámetros que han sido
transmitidos desde dicho controlador de red de radiocomunicaciones
de origen.
9. Método según la reivindicación 7, que
comprende además la etapa en la que se proporciona a la estación
móvil información sobre la validez o no validez de dichos
parámetros.
10. Sistema según la reivindicación 8, en el que
se proporciona a la estación móvil información sobre la validez o
no validez de dichos parámetros.
11. Método según la reivindicación 7, que
comprende además la etapa en la que se envían sustancialmente todos
los paquetes de datos en un modo sin compresión hasta que se haya
completado la negociación de los parámetros, en el caso de que se
hubiera averiguado que los parámetros no eran válidos.
12. Sistema según la reivindicación 8, en el que
sustancialmente todos los paquetes de datos se envían en un modo
sin compresión hasta que se haya completado la negociación de los
parámetros, en el caso de que se hubiera averiguado que los
parámetros no eran válidos.
13. Método según la reivindicación 1, en el que
por lo menos uno de los parámetros de compresión de encabezamientos
es un parámetro de identificación de intercambio (XID).
14. Sistema según la reivindicación 3, en el que
por lo menos uno de los parámetros de compresión de encabezamientos
es un parámetro de identificación de intercambio (XID).
15. Elemento de red en un sistema de
telecomunicaciones móviles, incluyendo el sistema una red central
(14) conectada (Iu) a diversos subsistemas de red de
radiocomunicaciones (11, 12) interconectados (Iur), para comunicarse
con una estación móvil (10) a través de una interfaz aérea
(Uu),
en el que un primero de entre dichos subsistemas
de red de radiocomunicaciones (11) incluye un controlador de red de
radiocomunicaciones de origen (16) para señalizar a dicha red
central o a un controlador de red de radiocomunicaciones de destino
(20) en un segundo de entre dichos subsistemas de red de
radiocomunicaciones (12) que se requiere un traspaso, y
en el que en respuesta a esto último dicha red
central o dicho subsistema de red de radiocomunicaciones de destino
señaliza al controlador de red de radiocomunicaciones de origen que
se va a poner en marcha dicho traspaso,
estando configurado dicho elemento de red para
proporcionar parámetros de compresión de encabezamientos de un
algoritmo de optimización desde dicho controlador de red de
radiocomunicaciones de origen hacia dicho controlador de red de
radiocomunicaciones de destino directamente o a través de la red
central sin ninguna necesidad de renegociar dichos parámetros a
través de dicha interfaz aérea entre dicha estación móvil y dicho
controlador de red de radiocomunicaciones de destino, y en el que
el elemento de red está destinado a ser usado en el controlador de
red de radiocomunicaciones de origen.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US16792499P | 1999-11-29 | 1999-11-29 | |
| US167924P | 1999-11-29 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2328218T3 true ES2328218T3 (es) | 2009-11-11 |
Family
ID=22609382
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES00974716T Expired - Lifetime ES2328218T3 (es) | 1999-11-29 | 2000-11-20 | Transferencia de parametros de algoritmo de optimizacion durante el traspaso de una estacion movil entre subsistemas de redes de radiocomunicaciones. |
Country Status (8)
| Country | Link |
|---|---|
| EP (2) | EP2053899B1 (es) |
| JP (1) | JP2003515995A (es) |
| CN (1) | CN1213630C (es) |
| AT (1) | ATE440469T1 (es) |
| AU (1) | AU1293001A (es) |
| DE (1) | DE60042790D1 (es) |
| ES (1) | ES2328218T3 (es) |
| WO (1) | WO2001039525A2 (es) |
Families Citing this family (36)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8959230B2 (en) * | 2002-01-28 | 2015-02-17 | Qualcomm Incorporated | Method and apparatus for negotiation of transmission parameters for broadcast/multicast services |
| US9635540B2 (en) | 2002-03-25 | 2017-04-25 | Jeffrey D. Mullen | Systems and methods for locating cellular phones and security measures for the same |
| JP4000906B2 (ja) | 2002-05-22 | 2007-10-31 | 日本電気株式会社 | パケット転送経路の最適化方法及びパケット転送装置並びにプログラム |
| WO2004093479A1 (en) * | 2003-04-17 | 2004-10-28 | Nokia Corporation | Protocol parameter re-negotiation after certain types of non-transparent data call handovers |
| FI116442B (fi) * | 2003-09-15 | 2005-11-15 | Nokia Corp | Pakettivälitteinen kanavanvaihto |
| WO2005089002A1 (en) * | 2004-03-11 | 2005-09-22 | Siemens Aktiengesellschaft | A method of packet switched handover |
| GB0405389D0 (en) | 2004-03-11 | 2004-04-21 | Siemens Ag | Inter-SGSN PS handover optimisation |
| EP1741256A1 (en) * | 2004-04-28 | 2007-01-10 | Nokia Corporation | Protocol parameter negotiation |
| CN1694381B (zh) | 2004-05-07 | 2011-08-24 | 日本电气株式会社 | 移动通信系统和mbms服务相关信息传送方法 |
| JP4552736B2 (ja) * | 2004-05-07 | 2010-09-29 | 日本電気株式会社 | 移動体通信システム及びそれに用いるデータ配信サービスの制御方法 |
| US8515424B2 (en) * | 2004-06-01 | 2013-08-20 | Qualcomm Incorporated | Connected-state radio session transfer in wireless communication systems |
| CN101040492B (zh) | 2004-06-01 | 2013-03-20 | 高通股份有限公司 | 无线通信系统中基于分组的切换系统和方法 |
| KR100640479B1 (ko) | 2004-06-07 | 2006-10-30 | 삼성전자주식회사 | 이동 광대역 무선접속 시스템에서 핸드오버 절차 최적화 시스템 및 방법 |
| FI20040817A0 (fi) * | 2004-06-14 | 2004-06-14 | Nokia Corp | Pakkausparametrien siirto matkaviestinjärjestelmässä |
| CN100370873C (zh) * | 2004-07-19 | 2008-02-20 | 华为技术有限公司 | 解决服务无线网络系统迁移后加解密失败的方法 |
| GB0418436D0 (en) * | 2004-08-18 | 2004-09-22 | Nokia Corp | Communication system |
| CN1319409C (zh) * | 2004-12-02 | 2007-05-30 | 华为技术有限公司 | 移动通信系统中保持连续通信的切换方法 |
| CN1889757B (zh) * | 2005-08-11 | 2010-05-12 | 华为技术有限公司 | 第三代移动通信系统中的业务切换方法 |
| ATE442017T1 (de) | 2004-12-02 | 2009-09-15 | Huawei Tech Co Ltd | Weiterreichverfahren in einem mobilkommunikationssystem zur sicherstellung der kommunikationsfortsetzung |
| US7167459B2 (en) * | 2004-12-30 | 2007-01-23 | Motorola, Inc. | Inter-network handover in a packet radio system |
| GB0507901D0 (en) * | 2005-04-19 | 2005-05-25 | Vodafone Plc | Controlling loads in telecommunications networks |
| US20070008902A1 (en) * | 2005-07-11 | 2007-01-11 | Saritha Yaramada | Managing negotiations of quality of service parameters in wireless networks |
| US20070155389A1 (en) * | 2005-12-31 | 2007-07-05 | Lucent Technologies, Inc. | Method for controlling header compression during handoffs in a wireless system |
| US8155651B2 (en) * | 2006-06-28 | 2012-04-10 | Telefonaktiebolaget L M Ericsson (Publ) | Transmission parameter negotiation after packet-switched handover |
| CN101237672B (zh) | 2007-01-29 | 2012-05-23 | 华为技术有限公司 | 一种演进网络中建立s1信令连接的方法、装置及系统 |
| US8886188B2 (en) * | 2007-03-20 | 2014-11-11 | Qualcomm Incorporated | Method and apparatus for transfer of session reference network controller |
| CN101299876B (zh) | 2007-04-30 | 2011-07-06 | 华为技术有限公司 | 同步方法、通信切换方法、无线网络以及节点 |
| CN102202358B (zh) * | 2007-04-30 | 2013-08-28 | 华为技术有限公司 | 同步方法、通信切换方法、无线网络以及节点 |
| FR2919977A1 (fr) | 2007-08-09 | 2009-02-13 | Alcatel Lucent Sas | Procede de gestion de changement de ressources radio affectees a un terminal mobile dans un systeme cellulaire |
| CN101136920A (zh) * | 2007-09-28 | 2008-03-05 | 华为技术有限公司 | 配置协商的方法及装置 |
| JP5397972B2 (ja) * | 2008-02-21 | 2014-01-22 | Ｎｅｃアクセステクニカ株式会社 | 音響通信システム、音声通信装置及び音声圧縮変更方法 |
| CN101827341B (zh) * | 2009-03-04 | 2013-06-05 | 电信科学技术研究院 | 一种单元格式的指示方法、系统和装置 |
| WO2010115303A1 (zh) * | 2009-04-08 | 2010-10-14 | 华为技术有限公司 | 小区信息的传递方法、网络设备和系统 |
| CN102300272B (zh) * | 2010-06-22 | 2015-09-16 | 中兴通讯股份有限公司 | S1切换的数据转发方法及移动通信系统 |
| US20150172421A1 (en) * | 2012-06-13 | 2015-06-18 | Telefonaktiebolaget L M Ericsson (Publ) | Data compression in a communications network |
| CN106936608B (zh) * | 2015-12-29 | 2020-09-18 | 华为技术有限公司 | 一种建立ssh连接的方法、相关设备及系统 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB9621247D0 (en) * | 1996-10-11 | 1996-11-27 | Nokia Mobile Phones Ltd | Dect/gsm interworking |
| FI105964B (fi) | 1998-12-16 | 2000-10-31 | Nokia Networks Oy | Menetelmä matkaviestinyhteyksien hallintaan |
| FI106762B (fi) * | 1999-02-16 | 2001-03-30 | Nokia Mobile Phones Ltd | Menetelmä ja järjestelmä eräiden neuvottelujen toteuttamiseksi pakettidataverkossa |
| GB2389751B (en) * | 1999-05-28 | 2004-02-25 | Nec Corp | Mobile telecommunications system |
| GB9921706D0 (en) | 1999-09-14 | 1999-11-17 | Nokia Telecommunications Oy | Relocation in a communication system |
-
2000
- 2000-11-20 AU AU12930/01A patent/AU1293001A/en not_active Abandoned
- 2000-11-20 CN CNB008163448A patent/CN1213630C/zh not_active Expired - Lifetime
- 2000-11-20 EP EP09153018.8A patent/EP2053899B1/en not_active Expired - Lifetime
- 2000-11-20 EP EP00974716A patent/EP1236363B1/en not_active Expired - Lifetime
- 2000-11-20 AT AT00974716T patent/ATE440469T1/de not_active IP Right Cessation
- 2000-11-20 WO PCT/IB2000/001709 patent/WO2001039525A2/en active Application Filing
- 2000-11-20 ES ES00974716T patent/ES2328218T3/es not_active Expired - Lifetime
- 2000-11-20 JP JP2001540545A patent/JP2003515995A/ja active Pending
- 2000-11-20 DE DE60042790T patent/DE60042790D1/de not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| WO2001039525A3 (en) | 2002-05-10 |
| JP2003515995A (ja) | 2003-05-07 |
| CN1213630C (zh) | 2005-08-03 |
| DE60042790D1 (de) | 2009-10-01 |
| WO2001039525A2 (en) | 2001-05-31 |
| EP2053899B1 (en) | 2016-07-13 |
| AU1293001A (en) | 2001-06-04 |
| EP2053899A1 (en) | 2009-04-29 |
| CN1402949A (zh) | 2003-03-12 |
| EP1236363B1 (en) | 2009-08-19 |
| EP1236363A2 (en) | 2002-09-04 |
| ATE440469T1 (de) | 2009-09-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2328218T3 (es) | Transferencia de parametros de algoritmo de optimizacion durante el traspaso de una estacion movil entre subsistemas de redes de radiocomunicaciones. | |
| ES2373710T3 (es) | Procedimiento de reubicación de srns y controlador de red radio correspondiente. | |
| ES2442892T3 (es) | Traspaso de conmutación de paquetes en un sistema de comunicación móvil, durante el que un nodo móvil recibe paquetes desde un nodo de origen y un nodo de destino | |
| US6968190B1 (en) | Transfer of optimization algorithm parameters during handover of a mobile station between radio network subsystems | |
| ES2262219T3 (es) | Actualizacion del area de encaminamiento en una red de radiocomunicaciones por paquetes. | |
| ES2745741T3 (es) | Gestión de traspaso | |
| ES2362173T3 (es) | Método de comunicación inalámbrica para transmitir una secuencia de unidades de datos entre un dispositivo inalámbrico y una red. | |
| ES2641834T3 (es) | Mecanismo de descarte eficiente en despliegue de células pequeñas | |
| ES2272691T3 (es) | Reubicacion de la informacion de contexto en la compresion de encabezamientos. | |
| ES2236319T3 (es) | Definicion de la compresion de campos de cabecera para conexiones de paquetes de datos. | |
| ES2648153T3 (es) | Método para procesamiento de protocolo de radio en sistema de telecomunicaciones móviles y transmisor de telecomunicaciones móviles | |
| EP2135471B1 (en) | Method and system for intra e-utran handover | |
| FI113323B (fi) | Datapakettinumeroiden synkronointi pakettivälitteisessä tiedonsiirrossa | |
| US20090034476A1 (en) | Packet data convergence protocol procedures | |
| ES2234212T3 (es) | Optimizacion de la actualizacion de area de encaminamiento en estado de espera para redes de radio por paquetes, multisistema. | |
| US20080188223A1 (en) | Method, a system and a network element for performing a handover of a mobile equipment | |
| ES2396205T3 (es) | Cambio de estación base sin pérdidas de comunicaciones de paquetes conmutados en modo no reconocido entre una estación móvil y una red de radio celular | |
| CN101473678A (zh) | 利用简单的隧道切换来改变lte特定锚点 | |
| US20090207739A1 (en) | Mobile communication system and method for transmitting pdcp status report thereof | |
| JP2008502188A (ja) | 移動体通信システムにおける圧縮パラメータの転送 | |
| KR100628743B1 (ko) | 무손실 에스알엔에스 재배치 방법 |