ES2702342T3 - Un nodo de red local - Google Patents

Abstract

Un nodo de red local, LNN, para transmitir mensajes entre un Equipo de Usuario, UE y una red compatible con Internet, el LNN que tiene una celda de cobertura en la que están situados uno o más UE, el LNN que comprende: una antena para transmitir señales a y recibir señales desde el UE, según un protocolo de radio celular; una conexión para transmitir mensajes a y recibir mensajes desde una red compatible con Internet; medios de conversión para convertir un mensaje entre el protocolo celular de radio y un protocolo de Internet de la red compatible con Internet caracterizado por que el LNN comprende además: una base de datos en la que se almacena un estado de cada UE de abonado en el área de cobertura del LNN, cada estado que indica un punto en el protocolo celular de radio o el protocolo de Internet que ha alcanzado un UE de abonado; en donde el LNN está configurado para determinar, para cada UE de abonado, qué mensaje en qué protocolo se requiere a continuación en una secuencia predeterminada para que una conexión sea establecida o para que la comunicación continúe, sabiendo qué mensaje se requiere a continuación en cada caso, la traducción de dicho mensaje siguiente se configura para que ocurra extrayendo los datos pertinentes a partir de un mensaje en un formato de protocolo y usando los datos extraídos para rellenar los campos pertinentes en un mensaje del otro formato de protocolo.

Description

DESCRIPCIÓN

Un nodo de red local

La invención se refiere a un sistema de comunicación y en particular a un sistema para conectar con un terminal de usuario en una red 3G.

Los sistemas de comunicación celular 3G y, en particular, el modo Dúplex por División de Frecuencia o Dúplex por División de Tiempo (FDD/TDD) del sistema de Acceso Múltiple por División de Código de Banda Ancha (WCDMA), definido por el Proyecto de Cooperación de Tercera Generación (3GPP), son conocidos y se describen en más detalle en www.3gpp.org.

El sistema de comunicación celular 3G dota a los abonados con la capacidad de transmitir texto, voz digitalizada, video y otros datos multimedia desde su teléfono móvil. El sistema está implementado actualmente por el Servicio Universal de Telecomunicaciones Móviles (UMTS), que se construye sobre la red existente del Sistema Global para Comunicaciones Móviles (GSM) y la tecnología del Servicio General de Radio por Paquetes (GPRS). La especificación inicial para UMTS se conoce como 'Versión 99', (R99) y define la arquitectura de red estándar para los sistemas UMTS. Más recientemente, se ha desarrollado la 'Versión 5' (R5), expandiendo la funcionalidad de la 'Versión 99' para incluir el Subsistema Multimedia IP (IMS). Esto proporciona una red inalámbrica basada toda en el Protocolo de Internet, en comparación con los elementos de red de voz, datos, señalización y control separados de los sistemas de la Versión 99. La arquitectura de la Versión 99 y la Versión 5 se describirá ahora con más detalle a modo de antecedentes y con referencia a la Figura 1.

La arquitectura de la Versión 99 se ilustra en la parte inferior de la Figura 1. El Equipo de Usuario (UE) 4 se conecta al Nodo B 6, el Nodo B al Controlador de Red de Radio (RNC) 8 y el RNC a un Centro de Conmutación Móvil (MSC) 10 en este caso el MSC_B. El MSC permite la interconexión a otras redes y a la Red Telefónica Pública Conmutada (PSTN) 12. El MSC_B tiene acceso al Registro de Posición Base (HLR) 14 y al Centro de Autenticación (AuC) a través del HLR.

Las funciones de los diversos elementos se describen brevemente como sigue:

1) El Nodo B es el equipo del sitio del transmisor, que contiene todo el aparato transmisor y receptor de radio necesario para la comunicación con el UE.

2) El Controlador de Red de Radio es responsable del control de los Nodos B y las conexiones de radio entre cualquier UE en el área de cobertura y el MSC.

3) El Centro de Conmutación Móvil es el dispositivo de circuitos conmutados que es responsable de controlar las conexiones normales de Circuitos Conmutados al UE. Típicamente comprende un conmutador telefónico normal, más la base de datos necesaria y funciones de procesamiento que son necesarias para gestionar llamadas hacia y desde los UE a medida que se mueven a través del área de cobertura de la red.

4) El Registro de Posición Base es una base de datos que almacena los detalles de un abonado específico, incluyendo sus datos de identidad y suscripción. El Centro de Autenticación es una entidad de red y procesamiento que proporciona información de seguridad bajo demanda de entidades de red que regulan el cifrado y la autenticación.

La mitad superior de la Figura 1 ilustra la arquitectura de red de IMS Versión 520. Además del Nodo B 22 y el RNC 24, hay un Nodo de Soporte GPRS de Servicio y un Nodo de Soporte GPRS Pasarela (SGSN/GGSN) 26 del dominio de Paquetes Conmutados PS y los componentes específicos de IMS tales como la Función de Control de Sesión de Llamada Intermediaria (P-CSCF) 28, la Función de Control de Sesión de Llamada de Servicio (S-CSCF) 30, el Servidor Local de Abonado (HSS) 32, la Función de Control de Pasarela de Medios (MGCF) 34 y la pasarela de medios (MGW) 34 que se conecta con la PSTN 36. Las sesiones de medios se establecen desde el UE 4 a través del dominio de Paquetes Conmutados (PS) y la P-CSCF y la S-CSCF. Si la sesión de medios es a través de una red externa tal como la PSTN u otra Red Móvil Terrestre Pública (PLMN), entonces también se requieren la MGCF y la MGW. La estructura y operación del IMS dentro de la arquitectura de red R5 son bien conocidos por los expertos en la técnica y se definen en las especificaciones del 3GPP TS23.002, TS24.228 y TS24.229.

El papel de los diferentes elementos se describirá ahora con más detalle:

1) El Nodo de Soporte GPRS de Servicio (SGSN) es el primer elemento responsable de conectar el UE a la red UMTS para servicios de datos de paquetes conmutados. El SGSN es responsable de una gama de servicios, tal como el registro de los UE para sesiones de paquetes de datos, y de gestionar la movilidad de los UE a medida que se mueven a través del área de cobertura.

2) El Nodo de Soporte GPRS Pasarela (GGSN) es la pasarela a las redes externas de paquetes de datos tales como Internet o el Sistema Multimedia IP, que gestiona las conexiones externas y otros asuntos tales como el control de la Calidad de Servicio (QoS).

3) La Función de Control de Sesión de Llamada Intermediaria (P-CSCF) es uno de los intermediarios SIP que se definen específicamente para su uso dentro de la arquitectura R5. El papel de la P-CSCF es proporcionar una pasarela s Ip al IMS y también proporcionar control de la QoS y negociación de las sesiones SIP.

El Protocolo de Iniciación de Sesión (SIP) es un protocolo estándar para iniciar una sesión de usuario interactiva que implica elementos multimedia tales como video, voz, charla y juegos. Igual que HTTP, SIP funciona en la capa de aplicaciones del modelo de Interconexión de Sistemas Abiertos (OSI), y puede establecer sesiones multimedia o llamadas de telefonía por Internet, y terminarlas. SIP se especifica en la Solicitud de Comentarios [RFC] 3261 del IETF.

4) La Función de Control de Sesión de Llamada de Servicio (S-CSCF) es otro intermediario SIP que se define específicamente para su uso dentro de la arquitectura R5. La S-SCSF proporciona control de sesión desde una perspectiva de servicio, tal como el registro de los UE para servicios SIP y autorizando los servicios específicos solicitados por los UE.

5) El Servidor Local de Abonado (HSS) es un superconjunto del Registro de Posición Base (HLR) que se definió para la red R99. El HSS es una base de datos que contiene toda la información que se requiere por una red para un UE específico, tal como la identidad del UE, las claves secretas usadas para procedimientos de seguridad y una lista de los servicios específicos que los UE tienen derecho a solicitar.

6) La MGCF es el dispositivo que es responsable de controlar las pasarelas de medios. La MGCF se usa siempre que hay una solicitud para conectar el UE a redes externas tales como la PSTN. La MGCF interactúa con la S-CSCF cuando una solicitud de una sesión SIP requiere el uso de conexiones a redes externas tales como la PSTN.

7) La Pasarela de Medios es el punto de contacto entre las redes externas, tales como la PSTN, y la arquitectura R5. La MGW convierte los medios entre diferentes tecnologías de transporte.

Como se puede ver a partir de la Figura 1, la conexión a cualquiera de estos sistemas es a través de un Nodo B, típicamente situado como parte de un mástil de radio en una localización elevada. En la medida que el uso de los terminales de usuario que proporcionan capacidades 3G llega a estar más extendido, no obstante, hemos apreciado que sería deseable permitir un control más específico sobre el acceso a la red, o bien para un grupo definido de terminales de usuario, o bien para terminales de usuario en una localización específica. Además, hemos apreciado que sería deseable que cualquier modificación o adición a la tecnología existente sea tanto compatible con los sistemas mencionados anteriormente, como lo suficientemente flexible para acomodar cualquier cambio al sistema que permita o trabaje con nuevas tecnologías a medida que se desarrollan.

El documento WO0237798 describe un aparato que convierte información de conformidad con un protocolo RTP en una forma susceptible de transmisión en un canal de radio, usando un protocolo de comunicación celular.

Compendio de la invención

La invención se define en las reivindicaciones independientes a las que se debería hacer referencia ahora. Las características ventajosas se exponen en las reivindicaciones adjuntas.

Breve descripción de los dibujos

Las realizaciones preferidas de la invención se describirán ahora con más detalle, a modo de ejemplo, y con referencia a los dibujos en los que:

La Figura 1 es una ilustración de las arquitecturas de red UMTS existentes que comprenden las arquitecturas de la Versión 99 y de la Versión 5.

La Figura 2 es una ilustración de un sistema según una realización preferida de la invención;

La Figura 3 es una ilustración esquemática de los protocolos lógicos empleados dentro del nodo de red local según una realización preferida de la invención;

La Figura 4 es una ilustración esquemática de los principales bloques de procesamiento en el nodo de red local según una realización preferida de la invención;

La Figura 5 es un diagrama de flujo que ilustra los pasos tomados para que el Equipo de Usuario se registre con el LNN;

La Figura 6 es un diagrama de flujo que ilustra los pasos que se llevan a cabo cuando un Equipo de Usuario no autorizado intenta acceder a una red móvil usando el LNN;

La Figura 7 es una ilustración esquemática de la configuración del sistema preferido configurado para la arquitectura de la Versión 99;

La Figura 8 es una ilustración esquemática de la configuración del sistema preferido configurado para la arquitectura de la Versión 5;

La Figura 9 es un diagrama de flujo que ilustra el procedimiento de registro para un primer Equipo de Usuario en una arquitectura de la Versión 99;

La Figura 10 es un diagrama de flujo que ilustra el procedimiento de registro para un segundo Equipo de Usuario en una arquitectura de la Versión 99;

La Figura 11 es un diagrama de flujo que ilustra el procedimiento para establecer una llamada entre el segundo Equipo de Usuario y una PSTN en una arquitectura de la Versión 99;

La Figura 12 es un diagrama de flujo que ilustra el procedimiento de registro para un primer Equipo de Usuario en una arquitectura de la Versión 5;

La Figura 13 es un diagrama de flujo que ilustra el procedimiento de registro para un segundo Equipo de Usuario en una arquitectura de la Versión 5;

La Figura 14 es un diagrama de flujo que ilustra el procedimiento para establecer una llamada entre el segundo Equipo de Usuario y una PSTN en una arquitectura de la Versión 5; y

La Figura 15 es una ilustración de un método de traspaso de llamadas según una realización preferida de la invención.

Descripción detallada de la realización preferida

La operación de una realización preferida de la invención se describirá ahora con más detalle con referencia a la Figura 2. La Figura 2 ilustra las arquitecturas de la Versión 99 y de la Versión 5 como se muestra en la Figura 1, y por lo tanto, a los componentes comunes se les ha dado el mismo número de referencia que antes. Además, se proporciona un Nodo de Red Local (LNN) 40 para gestionar el acceso del UE a las redes a escala local. Con el fin de acomodar el LNN en la arquitectura de la Versión 99, también se proporciona el elemento SIP/MSC_A 16, conectado de manera lógica al Ms C_B 10, al HLR/AuC 14 y a la PSTN 12.

Preferiblemente, el LNN se conecta a través de una conexión de Red IP Privada/Pública a la interfaz SIP del MSC_A, o de la Función de Control de Sesión de Llamada de Servicio (S-CSCF). El LNN también puede conectarse a la P-CSCF, aunque esto no se muestra en la Figura 2. Como se mencionó anteriormente, el UE 4 normalmente se conectaría a la red a través del Nodo B típicamente situado conjuntamente con una Estación Transceptora Base del sistema GSM subyacente. No obstante, el LNN proporciona un punto de acceso local controlado por el usuario para la red que se puede instalar en el hogar o en la oficina derivando la conexión a través de los Nodos B en conjunto. Típicamente, el punto de acceso será a través de una conexión ASDL a una línea telefónica en el hogar o en la oficina. De este modo, el LNN proporciona una celda privada al usuario.

El LNN conecta, por lo tanto, los UE en el área de cobertura con la red 3G, permitiendo que se acceda a los servicios 3G en el hogar o en la oficina a través de un punto de acceso local. De este modo, el LNN se puede operar en lugar de o además de una conexión telefónica privada estándar de un usuario. A lo largo de la descripción, el término red 3G se usa para referirse a cualquier sistema o red, incluyendo la interfaz de radio 3G en combinación con cualquier otra arquitectura de red, tal como GSM, PSTN. PABX, PBX, CDMA 2000, Redes de Próxima Generación (NGN), etc.

Un Terminal de Usuario de abonado puede, por lo tanto, acceder a la red a través del LNN y recibir servicios de red proporcionados bajo términos y condiciones específicos al LNN. Si el Usuario pasa fuera del área de cobertura proporcionada por el LNN, entonces tiene lugar preferiblemente un traspaso entre el LNN y un Nodo B adecuado de modo que la conexión del Usuario a la red 3G no se vea afectada sustancialmente.

El LNN está dispuesto para proporcionar conversión de protocolo entre los mensajes de control 3G recibidos desde el UE a los mensajes SIP/s Dp equivalentes requeridos para el mantenimiento de conexiones en redes basadas en el Protocolo de Internet, tales como la arquitectura de la Versión 5. Una vez que se ha establecido una conexión, cualquier dato del usuario, tal como paquetes de datos de habla o de video, se extraen de los Portadores de Acceso de Radio 3G, e introducen como paquetes en el flujo del Protocolo de Tiempo Real para su transmisión a través de la red basada en IP. Al convertir el paquete del protocolo 3G al protocolo rTp , los datos en sí mismos no necesitan cambiar, solamente la información de la cabecera del paquete necesita ser actualizada para adaptarse a cada protocolo respectivo.

La traducción entre protocolos se logra preferiblemente teniendo una disposición tal como una tabla de búsqueda de correlaciones entre los mensajes en los protocolos 3G y SIP/SDP, así como un registro del estado de cada UE conectado al LNN. En este contexto, el estado se pretende que indique el punto en un protocolo de comunicación que ha alcanzado el UE, tal como el que el mensaje 3G fue recibido por última vez desde el UE o transmitido a él.

Se apreciará que el intercambio de mensajes en cualquiera de los protocolos 3G o SIP/SDP se ajusta a una secuencia y formato predeterminados. De este modo, si se recibe un mensaje particular desde un UE, y se conoce el estado actual del UE, es posible determinar el siguiente mensaje, en cualquiera de los formatos 3G o SIP/SDP, que se requiere para que se establezca la conexión o para que la comunicación continúe.

La tabla de búsqueda se puede implementar como una máquina de estado, por lo tanto, en la que cada UE tiene un estado, como ACTIVO, INACTIVO y DESACTIVADO, por ejemplo, y en el que el movimiento entre estados desencadena una secuencia de mensajes predeterminada en cualquiera de los protocolos mencionados anteriormente.

Sabiendo qué mensajes se requieren en cada caso para la continuación de cualquier proceso que está en marcha, la traducción puede ocurrir simplemente extrayendo los datos pertinentes de un mensaje en un formato, y usando los datos extraídos para rellenar los campos pertinentes en un mensaje del otro formato. La traducción entre mensajes 3G y mensajes SIP/SDP se puede realizar, por lo tanto, en base a un proceso de adaptación de patrones. Los mensajes SIP/SDP son texto, permitiendo que los parámetros sean identificados y extraídos buscando nombres de campos particulares, por ejemplo, o extrayendo partes predeterminadas del mensaje a condición de que se entienda la función de esa parte. Los mensajes 3G se basan realmente en mapas de bits, pero el procedimiento de traducción se puede realizar tan simplemente como si estuvieran basados en texto. Preferiblemente, el mapa de bits se analizaría sintácticamente primero para convertirlo en componentes de texto, que luego se podrían manejar de la forma normal. La operación de cualquier traducción llegará a estar clara a partir de la discusión de la Figura 3 dada a continuación, y de las Figuras posteriores que ilustran los flujos de mensajes para procesos particulares entre el UE y la red a través del LNN. No todos los mensajes recibidos desde el UE requieren traducción, solamente los que se relacionan con el control o establecer un servicio de red por ejemplo.

La composición funcional del LNN se muestra con más detalle en la Figura 3 a la que ahora se debería hacer referencia. El LNN comprende un lado del Terminal de Usuario 42 que comprende una primera pila de procesamiento de protocolo para procesar datos 3G recibidos desde o transmitidos al Terminal de Usuario 50 sobre la interfaz aérea, y un Lado de Red 44 que comprende una segunda pila de procesamiento 60 para tratar con datos IP.

De forma conocida, la primera pila de protocolos contiene una Capa Física 51, por encima de la cual se sitúan la capa de Control de Acceso al Medio (MAC) 52 de la Capa 2, la capa de Control de Enlace de Radio (RLC) 53 de la Capa 2, la capa de Control de Recursos de Radio (RRC) 54 de la Capa 3, incluyendo la función de control de Portador de Acceso de Radio (RAB) 55, y la función de Estrato sin Acceso (NAS) 56 de la Capa 3 a su vez.

La capa Física gestiona la modulación de paquetes de datos desde las capas superiores sobre el portador de RF, incluyendo la aplicación de la difusión CDMA y códigos de aleatorización en aplicaciones UMTS. Por lo tanto, es responsable de la transmisión de datos sobre la interfaz aérea a través de un número de canales de transporte. La capa de Control de Acceso al Medio de la capa 2 gestiona el flujo lógico de datos desde las capas superiores a la capa Física y determina la correlación de los canales lógicos con los canales de transporte.

El Control de Enlace de Radio RLC de la capa 2 es responsable de definir diferentes tipos de servicios de transferencia de datos, esto es, Modo Transparente, Modo sin Acuse de Recibo y Modo de Acuse de Recibo, así como configuraciones de calidad de servicio, notificación de error irrecuperable, cifrado, etc.

La Capa de Control de Recursos de Radio 54 de la capa 3 maneja la señalización entre el terminal de usuario y la red, incluyendo el establecimiento, el mantenimiento y la liberación de conexiones, el control de potencia del bucle externo, el control de cifrado y el avance de temporización en el modo TDD, el informe de medición del terminal de usuario y la evaluación, así como la búsqueda y la notificación.

La capa de Control de Recursos de Radio 54 de la capa 3, junto con la función de Portador de Acceso de Radio 55, controla el establecimiento, el mantenimiento y la liberación de portadores de radio para la sesión de medios. Los Portadores de Acceso de Radio son responsables de transportar los datos de los medios, tales como datos de habla o video.

Por último, la función de Estrato sin Acceso 56 de la capa 3 controla la transmisión de información tal como la señalización de gestión de movilidad y los mensajes de control de llamadas.

Un mensaje recibido en un sistema 3G primero se recibirá por la capa física y fluirá hacia arriba a través de cada capa hasta la tercera o la capa de aplicaciones, donde se puede transmitir a través de la red al destinatario designado. A la recepción, el mensaje fluiría hacia abajo a través de las capas en la dirección opuesta. Estas capas se proporcionan típicamente en elementos distribuidos de la red. Para evitar dudas, se apreciará que los niveles más altos típicamente también tendrán una funcionalidad de nivel más bajo. Por ejemplo, en el Nodo B, la capa física extraerá la información de la capa 2 para su transmisión al RNC, pero luego usará una capa física diferente para transmitir la información de la capa 2 al RNC.

En sistemas 3G típicos, el Nodo B proporcionaría la capa física, el RNC proporcionaría la funcionalidad de la capa 2 y el RRC de la Capa 3 y el control de los RAB, mientras que el MSC o s Gs N proporcionaría el NAS de la capa 3. En la realización preferida, todas estas funciones están contenidas dentro del Nodo de Red Local.

La segunda pila 60 contiene una capa ADSL (Línea de Abonado Digital Asimétrica) 61, por encima de la cual se sitúan de manera lógica las funciones de Protocolo de Internet 62 y, a su vez, el Protocolo de Datagrama de Usuario 63. Por encima de la capa UDP están el Protocolo de Tiempo Real (RTP) 64 y el Protocolo de Iniciación de Sesión/Protocolo de Descripción de Sesión (SIP/SDP) 65.

El bloque ADSL controla la transmisión de la información digital en la línea telefónica de la red, según la información de encaminamiento proporcionada por el bloque de protocolo de Internet 62.

El Protocolo de Transporte en Tiempo Real es un estándar de protocolo de Internet que especifica una forma para que los programas gestionen la transmisión en tiempo real de datos multimedia sobre servicios de red o bien unidifusión o bien multidifusión. Sus funciones permiten que la transmisión de datos sea monitorizada de modo que se pueda compensar la pérdida y el retardo de paquetes. El bloque SIP 65, descrito con más detalle en la introducción gestiona los datos de control.

A su vez, ambos bloques típicamente se basan en el Protocolo de Datagrama de Usuario, que es responsable de asegurar que una unidad de datos, llamada datagrama, se reciba en el destino deseado. UDP es una alternativa a TCP y usa el Protocolo de Internet 62.

Un paquete de datos recibido desde el UE en la capa física 51, pasa a través de cada capa de la primera pila a su vez. Un número de puerto se asigna a una llamada por el LNN después de que se configura una conexión, y en cada capa el número de puerto y un identificador permiten que el LNN haga un seguimiento de cualquier paquete de datos que se relaciona con la llamada.

Si el paquete de datos es para datos de usuario, se asigna un Identificador de Portador de Acceso de Radio a los datos. Los datos de la llamada luego se extraen del Portador de Acceso de Radio en la parte superior de la pila 3G, y se introducen como un nuevo paquete en el protocolo de capa RTP de la pila IP. Haciéndolo así, se puede retener el número de puerto existente, o se puede generar un nuevo número de puerto para el paquete RTP. También se puede añadir un número de puerto de destino si se conoce (éste se asignará por la red, por ejemplo, en lugar de por el LNN). También se añaden las direcciones IP, tales como la de la dirección de red de destino, o del LNN desde el cual se originó la señal.

Los datos de control, por otra parte, se extraen de la capa NAS y se convierten en mensajes SIP/SDP como se ha descrito anteriormente. Esto se logra mediante el método de traducción mencionado anteriormente, que se basa en mensajes de correlación en los dos protocolos entre sí, dado el estado actual del UE.

De este modo, se recibe un mensaje codificado 3G desde un Terminal de Usuario por el LNN y se convierte en un mensaje codificado SIP para su transmisión a una red. La conexión entre el LNN y la red, podría ser a través de una conexión o bien por hilo o por cable a una línea telefónica dedicada, o bien de manera inalámbrica a un conector de línea telefónica.

La decisión de codificar mensajes de control en SIP, significa que para las redes de la Versión 99, será necesaria una conversión de vuelta a un protocolo de señalización adecuado. Como se muestra en la Figura 2, ésta se acomoda en la arquitectura de la Versión 99 por el SIP/MSC_A 16 a través del cual el LNN se conecta a la PSTN. El SIP/MSC_A está configurado para convertir los comandos del Protocolo de Iniciación de Sesión del UE 4, que se usan para establecer una sesión en una red IP, a los mensajes de la parte de Usuario ISDN (ISUP/SS7) usados para gestionar llamadas sobre una PSTN, y viceversa.

El SIP/MSC_A es, por lo tanto, una parte del sistema preferido que se proporciona fuera del LNN en la arquitectura de la Versión 99, e incluso en la arquitectura de la Versión 5 si se desea. Su operación se entenderá que es similar a la de las pilas de procesamiento de Internet y 3G proporcionadas en el LNN, excepto que un mensaje SIP se reciba y se convierta en el mensaje ISUP/SS7 pertinente para una red GSM. El método, por lo tanto, no se explicará en detalle aquí. También puede ser deseable proporcionar el SIP/MSC_A como parte de la arquitectura de la Versión 5. De este modo, cuando se instala un LNN, el UE se conectará preferiblemente a la red de la Versión 99 a través del LNN y del elemento SIP/MSC_A 16, y a la arquitectura de la Versión 5 a través del LNN y la S-CSCF 30. Alternativamente, el UE puede conectarse a la arquitectura de la Versión 5 a través del LNN y la P-CSCF. Qué implementación usar es una opción de diseño.

Los diversos protocolos descritos anteriormente en conexión con la Figura 3, están contenidos dentro de una unidad central de procesamiento alojada dentro del LNN. La estructura interna del LNN se describirá ahora con más detalle con referencia a la Figura 4.

La Figura 4 muestra el LNN 40, que tiene una antena 70, que puede ser interna o externa. Suponiendo que se usa un esquema de transmisión Dúplex por División de Frecuencia (FDD), la antena está conectada al filtro dúplex 72, que gestiona las dos frecuencias usadas para el enlace ascendente desde y el enlace descendente hacia el UE. El filtro 72 está conectado a Etapas de Receptor y Transmisor 74 y 76 separadas, respectivamente, que están conectadas a la unidad de procesador de banda base 78, mediante un Convertidor Analógico a Digital 80 y un Convertidor Digital a Analógico 82, respectivamente. En el lado del receptor, la unidad del procesador de banda base convierte la señal recibida identificada por el filtro dúplex en una señal de datos a presentar a la capa física y capas posteriores de la primera pila de protocolo 50. En el lado de transmisión, la unidad de procesador de banda base recibe una señal de la capa física y la pasa ésta a través del filtro dúplex para su transmisión a la antena. Se apreciará que si se usa el modo Dúplex por División en Tiempo entonces las frecuencias de enlace ascendente y de enlace descendente son las mismas, y el filtro dúplex se sustituye, por lo tanto, por un conmutador dúplex que separa las señales en el dominio del tiempo.

La unidad central de procesamiento 84 contiene un código que define los distintos protocolos de nivel ilustrados en la Figura 3 para el lado del Terminal de Usuario y el de la Red 42 y 44. También contiene la mayoría de las capas de protocolo mostradas en la Figura 3, así como el código necesario para transformar entre un protocolo y el otro en las capas superiores de cada pila de protocolo. En la realización preferida, esta es la tabla de búsqueda y el registro descrito más temprano.

Preferiblemente, no obstante, la capa ASDL se proporciona en la unidad de procesamiento de retroceso 86, que también contiene las funciones adicionales requeridas para asegurar que el enlace ASDL a la red opera de manera fiable. Éstas se entenderán por los expertos en la técnica y, así, no necesitan ser descritas aquí.

La CPU, por lo tanto, recibe señales digitales 3G desde la unidad de procesamiento en banda base y pasa las señales SIP a la unidad de procesamiento de retroceso 86, y desde allí a la red. La unidad central de procesamiento 84 contiene además el código de programa necesario para regular la operación del LNN en sí mismo, como se describirá más tarde.

Conectados a la Unidad Central de Procesamiento están la Interfaz de Usuario 88, tal como un botón y una pantalla, que permiten la selección de una serie de opciones de control que se pueden mostrar, y una base de datos local 90 para mantener un registro de terminales de usuario de abonado que pueden usar los servicios proporcionados por el LNN.

Una discusión de cómo un Equipo de Usuario se registra en el LNN para el acceso a la red se proporciona más tarde en conexión con la Figura 9.

El LNN, por lo tanto, es esencialmente un sistema celular 3G completo. El LNN es un compuesto de elementos de un Nodo B, un RNC y un MSC, o un SGSN/GGSN y una P-CSCF, dependiendo de cuál o ambas funciones de la Versión 99 y la Versión 5 se implementan. En la interfaz a la red R99, el UE por lo tanto se parecerá a un cliente SIP que establece conexiones con el MSC habilitado para SIP, usando el protocolo de señalización SIP. Los mensajes SIP se usan para transportar los mensajes de señalización al MSC, que luego se parecen a un MSC en lo que concierne al resto de la red externa.

En la interfaz entre el LNN 40 y la S-CSCF 30, el LNN parece un UE que comunica con la S-CSCF a través de una P-CSCF, o directamente con la P-CSCF. Todos los mensajes desde el LNN a la S-CSCF y la P-CSCF se definen por y se ajustan a la interfaz definida dentro de las especificaciones del 3GPP. La decisión en cuanto a qué arquitectura de red se conectará el LNN es una decisión del operador. Puede ser la arquitectura R99, o puede ser la arquitectura IMS R5.

Además, el LNN puede operar con otros tipos de red, esto es, redes inalámbricas tales como 3G, equipos PABX (Centralita Automática Privada), redes autónomas y una variedad de redes de datos tales como LAN y redes de tipo Internet en general.

Se entenderá que el término equipo de usuario incluye cualquier dispositivo con capacidades 3G, incluyendo terminales móviles tales como teléfonos móviles y asistentes digitales personales, ordenadores portátiles u otros dispositivos informáticos de palma o de mano, así como dispositivos típicamente no móviles tales como ordenadores de sobremesa.

El término red móvil también se entenderá que se refiere a cualquier arquitectura de red de telecomunicación o proveedor de servicios que pone a disposición una gama de servicios de telecomunicación para tal equipo de usuario.

Además, se apreciará que se podría usar cualquier número de esquemas de transmisión para la interfaz aérea entre el LNN y el UE. Puede ser deseable, por ejemplo, equipar al LNN con dos antenas de modo que se podría usar un esquema de diversidad de antenas.

Varios aspectos de la operación del LNN se describirán ahora con más detalle.

Registro

Un aspecto particular de la operación del LNN que requiere gestión es el mecanismo a través del cual el LNN puede decidir si aceptar un intento de registro desde un UE específico. En la macro red celular, e1HLR es responsable de la decisión final en cuanto a si se permite al abonado acceder a la red. La decisión se basa normalmente en el estado de suscripción y se hace después de un procedimiento de autenticación. Si el UE es válido y tiene la suscripción correcta, entonces se le permitirá acceder a la red.

Para el LNN, la situación es ligeramente diferente. El área o celda de cobertura del LNN no es una celda pública y, en consecuencia, la mayoría de los abonados potenciales necesitarán ser excluidos del uso de esta celda. Gestionar esta funcionalidad desde la macro red sería incómodo y conduciría a una gran cantidad de carga en la macro red. La realización preferida del LNN, por lo tanto, incluye una base de datos local o un registro 90 dentro del LNN. Esta base de datos define preferiblemente la dirección de los UE a los que se les permite acceder al LNN. El LNN entonces puede hacer un seguimiento de los LNN permitidos y solamente permitir los intentos de registro de aquéllos que se permiten.

Hay dos aspectos de la operación del LNN en este sentido. En el primer aspecto, se define un mecanismo en el cual se autoriza a un UE maestro a acceder al LNN y en el segundo aspecto se proporciona un mecanismo para controlar la autorización de los UE posteriores sobre el LNN. El LNN puede no requerir explícitamente la autenticación del UE con la macro red celular, pero ese procedimiento puede ocurrir.

En el primer aspecto, el UE se activa en las inmediaciones del LNN. Al mismo tiempo se alerta al LNN de que una autorización del UE está en curso a través de algunos medios adecuados, tales como la presión de un botón o conmutador conectado al LNN. La presión del botón o del conmutador activará el procedimiento de autorización para el UE que se está siendo activado actualmente. A su vez, el UE detectará el LNN e intentará registrarse con el LNN. En el proceso del registro el LNN puede solicitar la Identidad Internacional de Abonado Móvil (IMSI) o Identidad Internacional de Equipo Móvil (IMEI) del UE y almacenarla en una base de datos como un UE válido.

En el segundo aspecto, la interfaz de usuario 88 del LNN permite la presentación de y la modificación al estado de registro de los U^e que están registrados con el LNN. Este procedimiento permitirá la identificación de UE específicos, la última vez que los UE utilizaron el LNN y la eliminación de los UE de la base de datos, si se requiere. En la siguiente discusión del proceso de registro para un terminal de usuario, se supondrá que la interfaz de usuario 88 comprende un botón para interacción con las opciones de menú presentadas en una pantalla, tal como un visualizador LCD. No obstante, el LCD es opcional.

El Equipo de Usuario estará en las proximidades del LNN cuando se activa el procedimiento de registro, y al menos dentro del área de cobertura de la celda del LNN.

La Figura 5 ilustra el proceso de registro con el LNN. El botón en el LNN 40 se presiona y el UE se enciende y realiza su procedimiento de activación habitual, incluyendo una búsqueda de las PLMN dentro del área. La activación del UE en el área dentro de un período de tiempo específico de la activación del botón se toma para indicar que el UE ha de ser registrado como un equipo de usuario de abonado de LNN. Alternativamente, se podría hacer que el UE se registre con el LNN por el usuario que selecciona una opción de búsqueda de red manual para localizar el LNN, y para solicitar el registro.

Cuando el UE encuentra el canal de difusión del LNN, el UE intentará registrarse con el LNN y seguirá los procedimientos adicionales que se enumeran a continuación, e ilustran en la Figura 5.

1. El UE solicita y establece una conexión RRC con el LNN usando su procedimiento estándar;

2. El UE entonces realiza una actualización de localización para indicar que desea registrarse con el LNN. El UE intentará de hecho registrarse con la celda de cobertura más fuerte que detecta. Si el UE está dentro del área de cobertura del LNN, entonces es probable que el LNN proporcione la celda más fuerte a menos que el UE esté cerca del límite de la celda. En este caso, el UE puede intentar y registrarse con una macro celda colindante, o con una celda no autorizada. En ambos de estos escenarios, es posible proporcionar un mecanismo para que el usuario seleccione con qué celda registrarse.

3. Una función de control 92, proporcionada en la unidad central de procesamiento del LNN, entonces solicita que el UE proporcione su Identidad Internacional de Abonado Móvil (IMSI);

4. El UE transmite la IMSI a la función de control en el LNN;

5. La función de control en el LNN solicita que el UE proporcione su Identidad Internacional de Equipo Móvil (IMEI). Como es sabido en la técnica, la IMEI indica el fabricante y el número de modelo del Equipo de Usuario;

6. El UE proporciona la IMEI para el equipo terminal al LNN;

7. La función de control en la unidad central de procesamiento en el LNN solicita que la Base de Datos Local 90 sea actualizada para almacenar la IMSI y la IMEI como identidades que se permite que el LNN use;

8. El Registro Local almacena la nueva IMSI e IMEI y reconoce el registro a la función de control; y

9. Posteriormente, el resto del procedimiento de registro continúa según los procedimientos definidos para el UE, con el LNN actuando como intermediario. Este comprenderá el LNN que reenvía el mensaje de registro a la macro red y la macro red que autentica el Módulo de Identidad de Abonado UMTS (USIM) que está presente dentro del UE. Los detalles para esta etapa del procedimiento se definen para las macro redes y los UE en cuestión, y así no se considerarán en mayor detalle.

Una vez que se completa el procedimiento de registro, el UE se registra en el LNN, y cualquier solicitud posterior para usar el LNN se puede aprobar por el LNN.

De esta forma se puede registrar un UE maestro. Los UE posteriores se pueden registrar con el LNN y autorizar de una variedad de formas además del método perfilado anteriormente. En el segundo aspecto de la invención, el UE maestro podría, por ejemplo, transmitir un mensaje de texto o SMS al LNN para indicar que se debería autorizar un intento de acceso desde un segundo UE, si el segundo UE no está registrado actualmente. Para evitar un registro accidental por parte de un UE que no sea el UE previsto, se podría incorporar un código de autorización en el texto original o mensaje SMS y transmitir tanto al LNN como al segundo UE. El segundo UE podría usar entonces la solicitud de registro estándar e incorporar el código de autorización. Tales mensajes podrían aparecer en los siguientes formatos:

Mensaje de texto de UE maestro: “registrar UE 12345";

Mensaje de texto de segundo UE: “confirmar UE 12345”.

El LNN se dispondría entonces para detectar ambos mensajes y a la recepción del mensaje 'confirmar', registrar el segundo UE en la base de datos. Alternativamente, se podría realizar el registro del segundo UE, pero los detalles del segundo UE eliminar de las bases de datos, revirtiendo la autorización, si el mensaje confirmar no se recibió desde el segundo UE dentro de un período de tiempo predeterminado, tal como 1 minuto.

Si un UE que no está aprobado por el LNN intenta acceder al LNN, entonces se le denegará el acceso en la etapa cuando intente realizar un registro de localización. Este aspecto de la invención se ilustra en la figura 6 a la que ahora se debería hacer referencia. Los diferentes procesos dentro de la figura 6 se consideran a continuación. 10. En primer lugar, un UE visitante entra en el área servida por el LNN, o se activa dentro de ella, y selecciona el LNN para el acceso a la red. El UE solicita una conexión RRC del LNN;

11. El UE solicita una actualización de localización;

12. La función de control en la unidad central de procesamiento del LNN solicita que el UE proporcione su IMSI; 13. El UE transmite la IMSI a la función de control en el LNN;

14. La función de control en el LNN solicita que el UE proporcione su IMEI;

15. El UE proporciona la IMEI del equipo terminal al LNN.

16. La función de control verifica si la IMSI y la IMEI están autorizadas según la entrada almacenada en el registro local;

17. El registro local indica que la IMSI y la IMEI no están autorizadas, y envía un acuse de recibo negativo (NACK).

18. La función de control rechaza la solicitud de actualización de localización.

De este modo, solamente aquellos Equipos de Usuario que se han registrado correctamente con el registro local son capaces de usar el LNN para acceder a la red.

Sin el registro local, cualquier UE válido podría, en teoría, acceder al LNN. En muchos casos, debido a los recursos restringidos disponibles y los posibles problemas de facturación, esto no es aceptable. La realización preferida permite que la autorización local de los UE se logre, o bien a través de la IMSI o a través de la IMEI o bien equivalentes.

Aunque el registro del UE con el LNN se logró en el ejemplo anterior, presionando un botón, esto es puramente ilustrativo. Se podrían usar otras diversas técnicas para poner el LNN en un estado para registrar la IMSI y la IMEI, incluyendo cualquiera de las muchas implementaciones proporcionadas dentro de Interfaces Gráficas de Usuario conocidas o interfaces manuales. Además, el LNN podría sondear activamente a los UE dentro del área de cobertura que no están registrados y mantener una lista de los UE que están presentes pero que aún no están registrados. Éstos se podrían autorizar entonces más tarde por un operador seleccionando, a partir de los detalles almacenados, qué casos han de ser autorizados y cuáles no. Con el fin de hacer esto, podría ser útil incluir la dirección del UE o el número de teléfono en el registro también, de modo que se pueda identificar más fácilmente por un operador humano. La presión del botón también podría ocurrir antes, de manera sustancialmente simultánea con, o incluso después de la activación del Terminal de Usuario.

Además, aunque en el ejemplo anterior el registro con el LNN se logró presionando un botón, y activando el UE dentro del área de cobertura, el registro también se podría lograr usando la opción de búsqueda manual de red expuesta en el protocolo 3G para localizar el LNN y solicitar el registro.

Preferiblemente, el LNN también está dotado con la capacidad de revisar y modificar los contenidos de la base de datos local a través de la interfaz de usuario. Una pantalla LCD (o equivalente) se usa preferiblemente para presentar información al usuario. El botón se puede usar por su cuenta o posiblemente con botones adicionales para revisar y modificar contenidos del registro local. Un único botón puede ser preferido simplemente por facilidad de fabricación y operación.

En una realización preferida, el LNN está configurado para responder a una solicitud del usuario si se presiona el botón durante un período de tiempo predeterminado (digamos > 2 segundos). Esto haría que el visualizador presente la lista de UE registrados en el LNN e información relacionada con esos UE, tal como el número de llamadas hechas durante algún período de tiempo definido, digamos un mes, la última vez que se hizo una llamada y la duración de las llamadas. Una presión más aguda y más corta, por otra parte, activa el procedimiento de registro para un UE.

Usando el botón (posiblemente ahora con presiones cortas <1 segundo), el usuario puede seleccionar entonces cada entrada de la lista a su vez. Si se presiona el botón durante un período largo, se seleccionará esa entrada en la lista y se presentará un conjunto de opciones. Estas opciones podrían incluir 'borrar UE de la lista', 'restablecer llamada y contador de tiempo de llamada', 'establecer un límite de duración de llamada para el UE', etc. Una presión corta hará un ciclo a través de estas opciones y una presión larga seleccionará la opción. Cada opción se considera en detalle a continuación.

Una vez que se selecciona la opción de borrar UE para un UE resaltado, una presión larga hará que se elimine el UE y devolverá la función de control de vuelta al nivel superior del menú. Una presión corta moverá la función de control al siguiente elemento de la lista. Una vez que se seleccionan el restablecer llamada y el contador de tiempo de llamada, una presión larga restablecerá esos contadores para ese UE específico. Después de que se completa esto, la interfaz de usuario vuelve al nivel superior en la estructura del menú.

Una vez que se selecciona establecer el límite de duración de llamada con una presión larga, aparecerá un nuevo submenú que define los límites de duración de llamada, tales como 10 minutos por día, 30 minutos por día, 60 minutos por día y sin límite por día. Un administrador u operador hará un ciclo a través de estas opciones con la presión corta y seleccionará la opción con una presión larga. Después de que se completa esto, la interfaz de usuario vuelve al nivel superior en la estructura del menú.

De esta forma, se pueden configurar manualmente los servicios presentados a los UE a través del LNN por el administrador u operador. Las configuraciones pueden reflejar diferentes niveles de autoridad dentro del grupo que tiene acceso al ^lNⁿ , tal como empleados en una empresa, o controles parentales infantiles en el hogar.

Esta realización preferida, por lo tanto, propone un método a través del cual el LNN puede autorizar el acceso a los servicios proporcionados por el LNN. La autorización se controlará a través del LNN y requerirá la interacción del usuario para autorizar que un nuevo UE acceda al LNN. La autorización se puede basar en la IMSI o un identificador interno de red equivalente para un abonado, o podría ser la IMEI o un identificador de terminal equivalente para el equipo usado por el abonado. El primero permite al abonado usar el LNN independientemente del equipo terminal usado, el último autoriza al terminal a acceder al LNN independientemente del abonado que usa el terminal.

Método de gestión de direcciones

Con el fin de permitir que el LNN sea usado de manera flexible con una pluralidad de Terminales de Usuario, hemos apreciado que puede haber ocasiones en las que un Terminal de Usuario visitante, que es uno que no es un Terminal de Usuario de abonado, puede desear acceder temporalmente a la red a través del LNN en lugar de a través de cualquier Nodo B superpuesto.

Al hacerlo así, hemos apreciado que es deseable gestionar la llamada desde el terminal visitante como si se originase desde el terminal de abonado. Esto evita la necesidad de un registro separado del terminal de usuario visitante con el LNN y la red.

Manejar la llamada de esta forma, no solamente permite que el establecimiento de la llamada en sí mismo sea gestionado de una forma más efectiva, sino que también proporciona ventajas desde un punto de vista de uso de llamada y facturación.

En el uso normal de una red celular, por ejemplo, o bien se factura directamente al usuario a su cuenta, o bien sus llamadas se cargan a partir de una cuenta de prepago para ese usuario. Hay muchas circunstancias, no obstante, donde es beneficioso permitir que los usuarios facturen llamadas a una cuenta diferente.

Los dos siguientes escenarios específicos resaltan este requisito. En el primero, un usuario puede tener un LNN habilitado en su hogar. Un segundo usuario visita al primer usuario y desea hacer una llamada usando su propio teléfono celular. El primer usuario ofrece permitir al segundo usuario hacer la llamada a través de su LNN y poner la llamada en la cuenta del primer usuario.

En el segundo escenario, un usuario podría entrar en una unidad comercial, tal como una unidad de venta al por menor en un área de tiendas. El minorista puede tener una oferta especial que permita al usuario descargar, de forma gratuita, un elemento multimedia tal como, por ejemplo, un fragmento de audio o video que proporciona que compren algo en la tienda. En este escenario, la transacción se puede facturar entonces a la cuenta del minorista. Además, en entornos donde la única cobertura se proporciona por el LNN, debido a que ningún Nodo B proporciona cobertura adecuada, por ejemplo, tal disposición permitiría a cualquier usuario acceder rápidamente a la red, sin tener que 'abonarse' al LNN. Esto ahorraría tiempo en el establecimiento de una llamada, y podría ser crítico por seguridad, si alguna vez se necesita consultar a los servicios de emergencia. Además, como el alcance para el UE desde el LNN es probable que sea menor que el del Nodo B más cercano, la tasa de datos del enlace entre el UE y el LNN puede ser más alta.

En la actualidad, no existe un método fácil para lograr este requisito con los grados adecuados de seguridad y autenticación que se requieren. Por lo tanto, es crucial que cualquier procedimiento sea soportado dentro de los procedimientos de seguridad y autenticación actuales definidos para las redes inalámbricas tales como UMTS.

Las Figuras 7 y 8 muestran en detalle la configuración del sistema preferido para las arquitecturas de la Versión 99 y de la Versión 5, respectivamente. Hasta cierto punto estos diagramas repiten el contenido de la Figura 2, y así los elementos comunes a ambos conjuntos de diagramas se les han dado los mismos números de referencia.

En la figura 7, vemos parte de la arquitectura de red que es probable que esté presente cuando el LNN 40 se despliegue en una red que se una a la red CS normal tal como GSM. Hay dos UE 4 y 5 mostrados como unidos al LNN 40. Esto significa que ambos se han conectado al LNN de la forma habitual para recibir servicios de red. El UE 4 actuará como el UE maestro. Este UE podría estar separado del LNN 40, o ser integral al LNN 40 o bien en su totalidad o bien en parte. El otro UE 5 será el de un visitante que desea acceder a la red externa a través del LNN. En este escenario se supone que todos los UE dentro del área de cobertura tienen acceso al LNN independientemente del procedimiento de registro descrito anteriormente.

El LNN está vinculado a la interfaz SIP 15 del GMSC 16 a través de una red IP pública o privada 41. En la Figura 2, el GMSC se conoce como el SIP/MSC_A. No obstante, la Figura 7 muestra este elemento con más detalle y como que comprende dos partes separadas.

El GMSC 16 está vinculado al Registro de Posición Base (HLR) 14, la PSTN 12 y el MSC 10 (MSC_B). El MSC está vinculado a su vez al controlador de red de radio 8 que está vinculado a numerosos Nodos B 6. Numerosos UE 400 y 500 se muestran como vinculados a los Nodos B.

En la figura 8, se ilustra el caso donde el LNN está dispuesto para acceder a una red IMS de la Versión 5. La principal diferencia entre la figura 7 y la figura 8, es que el GMSC 16 y la entidad SIP 15 se han sustituido por una Función de Control de Sesión de Llamada de Servicio (S-CSCF) 30, (o P-CSCF) y una Función de Control de Pasarela de Medios (MGCF) 28. El HLR 14 se absorbe en el Servidor Local de Abonado (HSS) 32.

Para explicar este aspecto del sistema preferido, consideraremos dos ejemplos. El primer ejemplo será una secuencia de flujos de mensajes que se aplican a la arquitectura ilustrada en la figura 7, y el segundo ejemplo será una secuencia de flujos de mensajes que se aplican a la arquitectura en la figura 8. La realización preferida se basa en muchos mensajes que existen en los sistemas actuales, con los cambios necesarios con el fin de producir la funcionalidad deseada que se resalta en la discusión a continuación.

Ahora consideraremos la figura 9, que ilustra el proceso de registro para un primer Equipo de Usuario 4 con el LNN, para registrar y solicitar el servicio de una red basada en tecnología GSM. El primer U^e 4 puede ser el UE principal en lo que concierne al LNN, y el contra el cual se hará cualquier cargo de llamada por cualquier UE posterior que se una a la red, tal como el UE 5.

La Figura 9 muestra los mensajes en secuencia numérica, con los números dados en la figura correspondientes a los párrafos numerados expuestos a continuación.

1. Inicialmente, el UE detecta el LNN escaneando los canales comunes (tales como el Canal de Sincronización y el Canal Físico de Control Común Primario). Al detectar el LNN, el UE forma un mensaje Solicitud de Conexión ^r R^c , que indica que el UE desea hacer una conexión con el LNN, la naturaleza de la conexión, una identidad inicial para el UE y mediciones de celdas colindantes en las inmediaciones del LNN. Este mensaje se transmite al LNN que almacena la identidad del UE y los datos de medición para su uso futuro.

2. El LNN responde al UE enviando un mensaje Configuración de Conexión RRC, que define el tipo de conexión asignada. El mensaje se envía a la dirección desde la que se recibió el mensaje del UE, y se asigna una dirección temporal al UE por el LNN para su uso futuro.

3. A la recepción del mensaje, el UE envía un Mensaje Configuración de Conexión RRC Completa, que indica que el mensaje se recibió correctamente, y que define las condiciones para cualquier algoritmo de seguridad.

4. El UE 4 solicita una actualización de localización. La actualización de localización se usará para registrar el UE en el LNN y el GMSC 16. El mensaje es el mensaje estándar SOLICITUD DE ACTUALIZACIÓN DE LOCALIZACIÓN definido por los protocolos 3G, e incluye cualquier identidad de abonado móvil temporal (TMSI) antigua e identificador de área de localización (LAI) antiguo que se usaron por el UE previamente en la macro red, o alternativamente en el LNN si el UE fue el último conectado al LNN.

5. Si el LNN 40 no reconoce la TMSI del UE 4, entonces el LNN puede solicitar que la IMSI del UE se envíe al LNN. Esto es necesario porque el LNN no tiene una conexión directa con la red celular normal. Se apreciará que en una macro red de celda normal, un nuevo MSC podría recuperar la IMSI del UE a partir del MSC antiguo, en base a la TMSI que se había asignado al UE por el m Sc anterior. Aunque es posible disponer que el GMSC recupere la IMSI, en este caso, suponemos que LNN no tiene acceso directo al MSC antiguo. Como consecuencia, el LNN está configurado para solicitar la IMSI desde el UE en lugar de desde la red.

Para hacer esto, el LNN envía el mensaje SOLICITUD DE IDENTIDAD. Aunque este mensaje es estándar, su uso en este contexto no lo es. Normalmente, el mensaje se usaría en la macro red cuando se haya perdido la identidad temporal asignada al UE.

6. El UE responde al mensaje SOLICITUD DE IDENTIDAD con la RESPUESTA DE IDENTIDAD que contiene la IMSI para el UE y, a su vez, el LNN almacena la IMSI en la base de datos local para su uso futuro.

7. Con la IMSI obtenida desde el UE, el LNN 40 ahora se registra a sí mismo con la entidad SIP 15 y el GMSC 16. La IMSI se transfiere en el mensaje REGISTRO SIP estándar como la identidad de usuario privada que se define en la especificación TS23.003. Una IMSI está compuesta por un número de 15 o 16 dígitos compuesto por un código móvil de país de 3 dígitos (MCC), un código móvil de red de 2 o 3 dígitos (MNC) y un número de identidad de abonado móvil (MSIN) de 10 dígitos.

Un ejemplo de IMSI podría ser: 234150123451234, que indica que el MCC es 234 y el MNC es 15. La identidad de usuario privada SIP, según la especificación TS23.003, llegaría a ser entonces:

234150123451234@ims.mnc015.mcc234.3gppnetwork.org

Por lo tanto, la IMSI se incluye dentro del mensaje de registro SIP dentro del campo de Cabecera de Autorización. Al registrarse de esta forma, el LNN llega a ser un punto de conexión entre el sistema 3G dirigido al UE y la arquitectura de red accionada por SIP, tal como la arquitectura de la Versión 5. En el caso de la arquitectura de la Versión 99, la entidad SIP o interfaz extrae los datos pertinentes del mensaje SIP y los pasa al GMSC 16.

La conversión del mensaje 3G en mensajes SIP proporciona adaptabilidad y compatibilidad, ya que se puede proporcionar una única unidad LNN para cualquier tipo de red IP. En el caso de las redes de arquitectura de la Versión 99, todo lo que se necesita entonces es un módulo adicional que forma la interfaz SIP unida al GMSC. La traducción del mensaje SIP a un formato que el GMSC pueda entender se logra de la manera descrita anteriormente para el LNN, manteniendo una correlación de los mensajes SIP con los mensajes GSM dado el estado actual de la conexión.

8. Los contenidos pertinentes del mensaje REGISTRO, tales como la IMSI, la MNN y el MNC, se transfieren desde la interfaz SIP al GMSC convirtiendo el mensaje SIP al mensaje GSM adecuado. Esto se lleva a cabo de la misma forma que para la conversión entre protocolos en el LNN. La conversión se expresa aquí en términos de un procedimiento de señalización de Mensaje de SIP a MSC (mensaje SM) interno. El campo más importante será la IMSI.

9. Habiendo recibido la información acerca del UE de abonado desde el LNN, la entidad GMSC 16 recupera entonces los parámetros de seguridad para el UE desde el HLR 14, usando el mensaje estándar INFORMACIÓN_DE AUTORIZACIÓN_DE ENVÍO_MAP de 3G.

10. En respuesta, el HLR 14 crea un conjunto de vectores de autenticación, expuestos en el paso 11, para el UE 4 y los envía al GMSC 16 usando también el mensaje INFORMACIÓN_DE AUTORIZACIÓN_DE ENVÍO_MAP.

11. El GMSC 16 traduce los parámetros de seguridad recibidos a la interfaz SIP 15 usando el mensaje SM.

Si se requiere un alto grado de seguridad en la red, la respuesta de autenticación RES de1HLR se pueden retener en el GMSC, ya que no hay necesidad de que se transmita el LNN. Otros parámetros, tales como la clave de cifrado CK, la clave de integridad IK, el testigo de autenticación (AUTN) y el número aleatorio RAND todos necesitarán ser transmitidos al LNN 40, y el RAND y el AUTN necesitarán ser transmitidos además al UE 4.

12. La interfaz SIP 15 indica al LNN 40 que la solicitud de registro aún no ha tenido éxito enviando una respuesta '401 No Autorizado' al LNN. El vector de autenticación se devolverá dentro de la respuesta al LNN.

Este procedimiento es similar al de la mayoría de redes SIP que requieren registro. El primer mensaje del LNN incluirá la información de identidad para el UE, pero no incluye la respuesta (RES) desde el UE. Este es un número de 128 bits que se genera por el UE. Como consecuencia, el UE no se puede autenticar en la primera pasada. En el segundo intento el UE recibe la información de autenticación del HLR a través del LNN y entonces puede generar la respuesta correcta que se envía de vuelta al GMSC.

13. El LNN 40, posteriormente, extrae el parámetro de número aleatorio (RAND) y el testigo de autenticación (AUTN) de 401 respuesta y los envía al UE 4 en forma de un mensaje SOLICITUD DE AUTENTICACIÓN de 3G.

14. El UE 4 procesará los contenidos del mensaje de solicitud de autenticación, autenticará la red, comprobará la integridad del mensaje y calculará una respuesta (RES) que ha de ser devuelta al LNN 40 en la RESPUESTA DE AUTENTICACIÓN.

15. El LNN 40 recrea el mensaje de registro pero en esta ocasión incluye los RAND, AUTN y RES de modo que la red pueda autenticar el UE 40. Los datos se pasan a la interfaz SIP 15 en el campo de Cabecera de Autorización dentro del mensaje de registro.

16. La interfaz SIP 15 pasa los datos de autenticación al GMSC 16, de la misma forma que en el paso 8 anterior. El GMSC entonces compara la respuesta del UE 4, con la respuesta inicial del HLR 14 en el paso 10. Si son iguales entonces el UE 4 se considera que es auténtico y el registro puede proceder.

17. El procedimiento de registro entonces continúa con el mensaje Actualizar Localización de 3G estándar en el que el GMSC 16 actualiza el HLR 14 en cuanto a la localización del UE 4. El HLR transfiere los datos de suscripción para el UE al GMSC.

18. El HLR transmite los Datos de Abonado para el UE al GMSC.

19. El GMSC acusa recibo de la recepción de los datos de abonado.

20. El HLR acusa recibo de la recepción de la solicitud Actualizar Localización.

21. Una indicación del éxito del registro se pasa entonces desde el GMSC 16 a la interfaz SIP 15. Se crea la identidad de abonado móvil temporal (TMSI) por el GMSC y se pasa a la interfaz SIP junto con la identidad de área de localización (LAI).

22. La interfaz SIP 15 pasa la TMSI y la LAI al LNN 40, en forma de una respuesta '200 OK' que indica que el mensaje de registro fue un éxito. La entidad SIP también podría incluir una cabecera Expira en el mensaje por ejemplo para indicar la duración de tiempo del registro, si esto se desea.

23. El LNN 101 convierte el mensaje SIP en un mensaje 3G como para los pasos anteriores, y reenvía el éxito del registro, la nueva TMSI y la LAI al UE 4 usando el mensaje ACTUALIZACIÓN DE LOCALIZACIÓN ACEPTADA de 3G. El UE almacenará la TMSI y la LAI para su uso posterior.

24. Finalmente, el UE acusa recibo de la asignación de la nueva TMSI al LNN 40 con el mensaje REASIGNACIÓN TMSI COMPLETA.

El primer equipo de usuario 4 se registra entonces a través del LNN con la red, y puede usar los diversos servicios multimedia especificados en el HLR.

Con referencia a la figura 10, ahora consideraremos el registro y la autenticación de un segundo UE 5. El procedimiento será básicamente el mismo que en el ejemplo anterior, pero diferirá al menos en el punto cuándo se asigna la TMSI y en la dirección dada al UE.

La decisión sobre qué TMSI asignar al segundo UE se toma por el LNN con el fin de organizar la cuenta en la que se hacen los cargos de llamadas. Un UE que solicite un servicio tal como una conexión de habla desde el LNN necesitará un número de puerto del LNN para que tenga lugar la comunicación entre el LNN y el UE. El flujo de medios desde el LNN se envía entonces a través de una conexión IP/UDP/RTP desde el LNN al GMSC.

Preferiblemente, la TMSI se asigna al UE de tal manera que el número de puerto asignado al UE se definirá en parte por la TMSI. Por lo tanto, el LNN asigna 10 bits de la TMSi para representar el número de puerto, dejando que los 22 bits restantes se generen aleatoriamente. La TMSI de 32 bits parecerá entonces:

TMSI = [22 bits aleatorios] [10 bits asignados]

El número de puerto UDP también necesitará ser asignado al UE en un punto posterior. Preferiblemente, el número de puerto UDP de 16 bits se asigna como sigue por el LNN:

Puerto UDP = [1] [10 bits asignados de la TMSl] [5 bits derivados de RAB-ld]

Los 5 bits derivados de RAB-ld se dan por:

5 bits = 2 * (RAB-Id -1)

El RAB-ld se representa típicamente como un número de cuatro bits, e identifica para un flujo de medios en particular el Portador de Acceso de Radio que se usará. El número de puerto adicional se incluye para permitir que el Protocolo de Control en Tiempo Real (RTCP) tome normalmente el siguiente número de puerto adyacente al número de puerto RTP.

Usando este planteamiento, somos capaces de asociar la TMSI al número de puerto, y asignar hasta 1024 TMSl por LNN. Tal número grande está muy por encima de las capacidades del LNN, así como las capacidades de los otros protocolos de señalización. Además, el número de puerto está definido implícitamente por la TMSI y el RAB-ld para el servicio específico.

El LNN mantendrá la asociación entre la TMSI asignada al GMSC y la TMSI asignada al LNN, usando una tabla de búsqueda almacenada en la base de datos local, por ejemplo.

El propósito de asignar una TMSI local es coordinar la asignación de las TMSl al puerto y al flujo de medios que definen los parámetros para el UE. Esto permite que los dos grupos de información TMSI, y los parámetros de Flujo de Medios se manejen de manera más eficiente, evitando la necesidad de una tabla de búsqueda y procesamiento para hacer un seguimiento de las TMSl para cada UE. Esto proporciona un método simple de asociación de números de puertos a las TMSl.

Ahora supondremos que el usuario quiere registrar el UE 5 con la red a través del LNN 40. Para activar el procedimiento, el usuario necesitará desencadenar una solicitud de conexión RRC como se muestra en los pasos iniciales de la Figura 9, para registrarse con el LNN. Cualquier conexión existente con un nodo B superpuesto se terminará durante este procedimiento y el UE ya no estará accesible más a través de la macro red. Esto se podría lograr seleccionando una opción “Ir” de la interfaz de usuario del UE proporcionada en el UE. La opción 'Ir' activaría un programa escrito en un lenguaje adecuado, tal como el Juego de Herramientas de Aplicación USIM (USAT) o Java. El programa en sí mismo se podría enviar al usuario desde el operador del LNN, de una manera similar a la forma en que los tonos de llamada y las imágenes de fondo se envían a los móviles actuales. Activar el programa Ir, no obstante, hace que comience el procedimiento de registro.

Alternativamente, se podría hacer que el UE realice una selección de PLMN manual, forzando al UE a realizar una actualización de localización.

Los pasos 25 a 46 de la figura 10 son esencialmente los mismos que las etapas 1 a 22 descritas previamente para el UE 4. Surgirán diferencias en los datos reales que se transmiten debido a las diferentes IMSI, diferentes vectores de autenticación y diferentes TMSI que se asignan al segundo UE.

Después de que se recibe el '200 OK' por el LNN 40 en el paso 46, o bien el LNN o bien el UE 4 de usuario maestro puede confirmar si debería seguir el registro para el UE25. El mecanismo para obtener la confirmación del UE 4 no se tratará aquí en detalle, pero podría basarse en el uso del servicio SMS, una activación de un contexto PDP o una mini aplicación de Java que se desencadena, para transmitir información entre el LNN y el UE. Tales opciones de mensajería son bien conocidas en la técnica. El mecanismo no afecta los principios básicos de esta invención. Para que la confirmación sea proporcionada desde el LNN, se podría proporcionar un botón especial u opción de menú en una interfaz gráfica de usuario.

47. Suponiendo que el usuario a través del UE 4 apruebe el registro, el mensaje ACTUALIZACIÓN DE LOCALIZACIÓN ACEPTADA se pasa al segundo UE 5 por el LNN. No obstante, en lugar de pasar la TMSI asignada por el GMSC 16, el LNN pasa la TMSI creada por el Ln N en sí mismo.

48. El UE 5 confirma la recepción de la nueva TMSI con el mensaje REASIGNACIÓN DE TMSI COMPLETA.

Para recapitular, en esta etapa, el primer UE tiene una TMSI recibida desde el GMSC en la red, mientras que el segundo Ue ha recibido una TMSI asignada por el LNN localmente.

Con referencia ahora a la Figura 11, consideraremos los flujos de mensajes que ocurren para establecer una llamada de habla entre el segundo UE25 y la PSTN 12.

49. El segundo UE 5 solicita el establecimiento de una conexión MM multimedia. Esto permite que una conexión de señalización entre el UE y el GMSC 16 sea creada y permite el establecimiento de una conexión de habla. Esto se logra a través de la transmisión de la Solicitud de Servicio CM. El segundo UE incluye la TMSI asignada por el LNN, de la forma normal, permitiendo al LNN identificar qué UE está solicitando la conexión.

50. El LNN 40 envía el mensaje COMANDO DE MODO DE SEGURIDAD al segundo UE 5, y en el paso 51 recibe el mensaje MODO DE SEGURIDAD COMPLETO en respuesta. Estos dos mensajes se usan para activar la protección de integridad y, opcionalmente, el cifrado entre el UE 5 y el LNN 40. La protección de integridad usará claves de seguridad que fueron derivadas por el UE.

52. El UE 5 envía el mensaje CONFIGURACIÓN que define el servicio específico solicitado. Éste se envía al LNN 40. El mensaje CONFIGURACIÓN define el Identificador de Flujo para la sesión de medios, que se usará por el LNN más tarde para asignar un RAB-ld.

53. El LNN 40 extrae la información adecuada del mensaje CONFIGURACIÓN para crear un mensaje INVITAR. La solicitud INVITAR es un mensaje que se define en un estándar del Grupo de Trabajo de Ingeniería de Internet, y que se usa para iniciar una sesión de medios. El formato de un mensaje típico se muestra a continuación.

INVITE sip: top_twenty_hits@some_network.com SIP/2.0

Via: SIP/2.0/UDP

UE4@lnn_network.com; branch=z9hG4bKnashds8; received=193.10.21.1

Max-Forwards: 70

To: Music Download <sip:top_twenty_hits@some_network.com>

From: UE4 <sip:UE4@lnn_network.com>;tag=4921211732

Call-ID: 23a56bc2ef

CSeq: 314160 INVITE

Contact: <sip:UE4@lnn_network.com>

Content-Type: application/sdp

Content-Length: 142

Los parámetros anteriores están seguidos por los parámetros SDP, que definen términos tales como los tipos de medios, los anchos de banda requeridos, los números de puertos, el protocolo de transporte, etc.

Para la dirección 'from' del mensaje INVITAR, se usa la IMSI del UE 4 dado que éste es el UE maestro para los propósitos del ejemplo, y no la IMSI del UE5 que está solicitando la conexión. Esto asegurará que la conexión pertenezca al UE maestro y, en segundo lugar, que la facturación de la conexión se cargue a la cuenta del UE 4 y no del UE 5. Por otra parte, el resto del mensaje invitar contiene los datos de conexión necesarios, tales como TMSI, Número de puerto, UDP y datos de RAB para encaminar la llamada al segundo UE, no al primero. Esto no se muestra explícitamente anteriormente, ya que estos parámetros están incluidos en la parte SDP del mensaje. Al menos se requiere que el número de puerto del segundo UE sea incluido en el mensaje para asegurar que los datos se encaminen a la localización final correcta.

Los parámetros SDP dentro del mensaje INVITAR definen los parámetros de los medios, tales como las conexiones UDP que han de ser usadas para los medios. El número de puerto para la conexión UDP se derivará del Identificador de Flujo enviado en el mensaje CONFIGURACIÓN y los 10 bits inferiores de la TMSI como se perfiló anteriormente. El Identificador de Flujo se devolverá en una etapa posterior por el GMSC 16 como el RAB-ld para el flujo de medios. La dirección IP usada por el LNN para todos los usuarios y sus flujos de medios puede ser la misma, solamente que necesitará ser diferente el número de puerto.

54. La interfaz SIP 15 reenvía el contenido del mensaje INVITAR al GMSC usando el MENSAJE SM descrito anteriormente en el paso 8, y en el paso 55, se envía un acuse de recibo desde el GMSC a la interfaz SIP.

56. La interfaz SIP genera entonces una respuesta estándar '183 Progreso de Sesión', que contiene la información necesaria del GMSC 16 para definir el flujo de medios desde la perspectiva del GMSC. Esto incluirá los tipos de medios preferidos, la dirección IP para el flujo de medios en el GMS^c y los números de puertos.

57. El mensaje LLAMADA EN CURSO se pasa al segundo UE 5 que indica que la llamada va adelante.

58. Un 'Acuse de recibo fiable provisional (PRACK) se envía entonces desde el LNN 40 a la interfaz SIP 15.

59, 60 y 61. La interfaz SIP 15 notifica al GMSC 16 que la llamada está en curso usando un mensaje SM del tipo descrito anteriormente. El GMSC acusa recibo de la notificación y solicita el establecimiento de un Portador de Acceso de Radio RAB para el flujo de medios. La interfaz SIP devuelve ‘200 OK' en respuesta al mensaje PRACK del LNN.

62/63. El RAB se crea posteriormente por el LNN y se notifica al segundo UE. El RAB-ld asignado será el mismo que el Identificador de Flujo en el mensaje CONFIGURACIÓN recibido desde el segundo UE en el paso 52. Se puede usar para definir el número de puerto como se ha definido previamente. En el paso 63, el UE transmite un mensaje ‘Completa' al LNN que indica que ha completado la configuración del Portador de Radio.

64/65. El LNN transmite un mensaje ACTUALIZACIÓN enviado al GMSC a través de la entidad SIP, indicando que los recursos RAB están disponibles desde el UE para el LNN.

66. Un Mensaje Dirección Inicial se envía entonces desde el GMSC 16 a la PSTN 12, indicando que la llamada está yendo adelante, y que está comenzando la parte de destino de la llamada.

67/68. Un ‘Acuse de recibo' que indica la recepción del mensaje ACTUALIZACIÓN se envía al LNN desde el GMSC a través de la interfaz SIP.

69 a 73. El mensaje dirección completa se envía entonces desde la PSTN 12 al GMSC 16, y posteriormente el mensaje Alerta. Éste se convierte en el mensaje 180 sonando para su transmisión al LNN, que a su vez se transmite como un mensaje Alerta de 3G al UE 5.

74-77. El mensaje PRACK transmitido desde el LNN acusa recibo de manera fiable del 180 Sonando a la interfaz SIP 15, que se comunica con el GMSC para devolver un mensaje 200 OK en el paso 77.

78 a 84. El mensaje Respuesta se recibe por el GMSC a través de la red desde el destino de la llamada, tal como un UE similar a los UE 400 y 500, y envía al UE a través de un ‘200 OK' de la interfaz SIP al LNN, y a través de un CONECTAR desde el Lⁿ N al UE. El UE acusa recibo con el ‘ACK DE CONECTAR' que se envía al GMSC a través del ACK de SIP.

85 a 87. La sesión de medios se inicia ahora y los medios, tales como datos de voz, fluyen ahora a través de la conexión definida por los parámetros SDP en el mensaje INVITAR inicial y en los mensajes 183 progreso de sesión posteriores. Desde el segundo UE, los medios pasan a través de un RAB al LNN, luego a través de una conexión IP/UDP/RTP al GMSC; y luego a través del GMSC a la PSTN a través de una conexión Múltiplex por División en el Tiempo (TDM).

La llamada se activa entonces, y los datos fluirán entre el segundo UE 5 y la PSTN 12 a través de una conexión que pertenece al UE maestro 4. Dado que la identidad del UE maestro fue sustituida dentro del mensaje INVITAR, la información de facturación recopilada se relacionará con el registro del UE maestro 4 y no con el segundo UE 5. Mientras tanto, la sustitución de la TMSI asignada localmente para el segundo UE para la recibida desde el GMSC permite al LNN procesar fácilmente los datos de conexión para el segundo UE. Especificando el número de puerto en la TMSI, el LNN no necesita buscar el número de puerto con el fin de gestionar la llamada, ya que la dirección se puede obtener a partir de la TMSI. Esto evita la necesidad de una tabla de búsqueda y hace la implementación del LNN más eficiente.

Las Figuras 12, 13 y 14 muestran la disposición correspondiente suponiendo que se está usando la arquitectura de la Versión 5. El modo básico de operación es el mismo que se ha descrito anteriormente para las Figuras 9 a 11. A continuación nos centraremos en las diferencias entre esta realización y la anterior y también los aspectos clave de la invención. Las etapas donde los mensajes son esencialmente los mismos que en la primera realización hacemos referencia directamente a esa realización.

Los pasos 1 a 7 son, por lo tanto, idénticos a los pasos 1 a 7 anteriores.

8. El procedimiento de autenticación dentro del IMS se define en la especificación TS24.228, y usa el protocolo DIAMETER definido por el IETF. La S-CSCF 30 recibe un vector de autenticación desde e1HSS 32 en base a la dirección del UE. En este caso, se usa el mismo procedimiento para definir la identidad de usuario privado de IMS del UE en base a la IMSI como se define en el paso 7 anterior.

Los pasos 9 a 12 son idénticos entonces a los pasos 12 a 15 anteriores.

12b. La S-CSCF confirma que el UE es auténtico y solicita al HSS que transfiera los datos de abonado. Los datos de abonado podrían incluir un número de identidades de usuario SIP públicas para el UE. Dependerá de la configuración en el HSS. Estas múltiples identidades públicas se podrían asignar más tarde a los usuarios que solicitan una identidad temporal para el servicio, o se podría usar una identidad pública única con los números de puertos que se usan para diferenciarse como antes.

Los pasos 13 a 15 son idénticos a los pasos 22 a 24 anteriores. El UE maestro se registra entonces con el LNN y la red.

La Figura 13 muestra pasos similares (pasos 16 a 30) como la figura 10, excepto por las diferencias en cómo interactúan los elementos dentro de la red. Por ejemplo, no se requiere ninguna interfaz SIP o GMSC, lo que significa que se pueden omitir los mensajes SM. La TMSI que se asigna al UE 5 en el paso 29 anterior en principio será la misma que antes.

La Figura 14 incorpora los mismos principios y mensajes definidos en la figura 11. Siendo la principal diferencia que los mensajes entre la S-CSCF 30 y la ^m G^c F 28 sustituyen los mensajes de la interfaz SIP 15 y el G^m SC 16.

En la descripción anterior, el UE 4 se ha descrito como separado del LNN 40. En realizaciones alternativas, es posible que el UE 4 esté integrado en el LNN o bien totalmente, o bien en parte. Específicamente, se requiere el USIM del UE, ya que éste se usa para autenticar el UE1 4 y asignar las direcciones de red a ser usadas posteriormente. Esto permite que el lNn y el UE 4 sean situados en tiendas, donde el UE 4 actuará principalmente como el terminal lógico para la llamada, en lugar de ser usado como el teléfono físico en sí mismo.

Traspaso de llamada

En las PLMN típicas, como se ha descrito anteriormente, los usuarios y sus UE se mueven a través de la red y la movilidad del usuario se gestiona típicamente a través de procedimientos a los que se hace referencia a menudo como traspasos (tal como en GSM) o reubicaciones (tal como en 3G). Nos referiremos a ellos aquí genéricamente como traspasos. A través de un traspaso, la conexión entre el UE y la estación base puede cambiar posiblemente a una nueva estación base o a una nueva frecuencia en la misma estación base.

Hay muchas formas de traspaso definidas, siendo algunos ejemplos definidos en la especificación TS 23.009 del 3GPP. Según la especificación TS23.009, se hace referencia a los traspasos que usan el mismo MSC antes y después del traspaso como traslados intra-MSC (reubicación SRNS en 3G), y se hace referencia a los que usan diferentes MSC antes y después como traspasos inter-MSC (reubicaciones SRNs inter-MSC en 3G).

Para acomodar a un usuario que abandona o entra en el área de cobertura proporcionada por el LNN, hemos apreciado que sería deseable permitir que tenga lugar un traspaso entre el LNN y el MSC o SRNS de la red superpuesta.

En una red sin el LNN, esto se podría lograr simplemente a través del uso de traspasos entre celdas, implementados en parte por funciones de control de celda tales como el BSC en GSM o el RNC en UMTS.

No obstante, con el LNN, no hay acceso directo a estas entidades, ya que el LNN se conecta directamente a la red central y, consecuentemente, la transferencia de llamada no se puede implementar a través de los mecanismos de traspaso descritos anteriormente.

El LNN, según la realización preferida, permite por lo tanto la modificación de los mensajes SIP que se intercambiarán entre el LNN y la red central.

Para una reubicación SRNS inter-MSC convencional entre diferentes entidades de la red central, se intercambian una serie de mensajes. Ejemplos de estos mensajes se definen en las especificaciones TS23.009 y TS29.002 para la reubicación de SRNS inter-MSC. Los mensajes se basan en el uso del protocolo RANAP y del MAP definidos en las especificaciones TS25.413 y TS29.002, respectivamente.

Haciendo adiciones a los intercambios de mensajes SIP que fluyen entre el LNN y el SIP/MSC_A, es posible permitir la incorporación de los mensajes que se definen en las especificaciones TS25.413, TS23.009 y TS29.002 para la reubicación de SRNS inter-MSC. A través de este procedimiento, será posible transferir la conexión desde el LNN a otro MSC dentro de la red central.

En esta descripción, consideraremos una PLMN que se define según las especificaciones de 3GPP. Existen otros tipos de PLMN para los cuales se podría usar también el esquema de procedimiento a continuación. Las diferencias están en los nombres aplicados a los mensajes, no en los principios que subyacen detrás de la transferencia de los mensajes.

Ahora se hará referencia a la Figura 15 que ilustra los flujos de mensajes entre el LNN y la macro red de la Versión 99, permitiendo la movilidad durante la llamada deseada. Obsérvese que los mensajes de señalización SS7 entre el MSC_A y el MSC_B se han omitido para simplificar la figura, pero son bien conocidos por los expertos en la técnica con los ejemplos presentados en la especificación TS23.009. El MSC_A y el MSC_B se supone que son los mostrados en la Figura 2. Se supone que el UE a punto de abandonar el área de cobertura del LNN, también ha detectado la celda producida por el Nodo B 6. El RNC_B mostrado en la Figura 15, por lo tanto, corresponde al RNC 8 en la Figura 2.

1. El procedimiento comienza como consecuencia de un informe de medición que el UE transfiere al LNN. Tales informes se hacen a intervalos constantes por los UE con el fin de asegurar que los canales de llamada se reciban con la intensidad adecuada y para asegurar que pueda ocurrir el traspaso de la llamada. El informe de medición contiene información de medición hecha por el UE para celdas en la misma frecuencia, diferentes frecuencias y diferentes Tecnologías de Acceso de Radio (RAT), suponiendo que el UE tiene conocimiento de las diferentes RAT y las diferentes frecuencias. La información de medición contendrá los resultados de las mediciones, tales como mediciones de RSCP, Ec/No y de pérdidas de trayecto, así como otra información requerida sobre el código de aleatorización de la celda y la id de la celda.

En base a las mediciones recibidas, el LNN puede decidir si realizar un traspaso a la macro red. La decisión se basa en la calidad percibida determinada de la conexión para la celda actual del LNN, y la calidad percibida de cualquier macro celda superpuesta de la red. La decisión se toma quizás con referencia a un umbral de calidad mínimo. Tales técnicas son ampliamente conocidas en redes móviles.

2. Si el LNN decide que realizará el traspaso a una macro celda detectada por el UE, entonces procederá generando y transmitiendo un mensaje REFERIR SIP al MSC_A. Aunque este mensaje está definido en el estándar SIP genérico, la presente realización proporciona correcciones al mensaje para efectuar un traspaso desde el LNN. El mensaje REFERIR SIP generado por el LNN incluye por lo tanto información modificada en forma de información de contexto SRNS que se necesitará por el nuevo RNC. Esto define información que se relaciona con los servicios que están activos actualmente, incluyendo elementos tales como la identidad RAB, los parámetros de Calidad de Servicio de RAB, las claves de seguridad actualmente en uso y los algoritmos que se usan. Además, también se incluyen otros elementos de NAS, tales como la IMSI.

Esta información normalmente formaría los contenidos del mensaje Solicitud de Reubicación que un RNC enviaría al MSC en un sistema normal para efectuar el traspaso. No obstante, en el sistema preferido, esta información se puede incluir en una nueva cabecera REFERIR SIP con un nombre tal como:

P-Relocation-lnformation: Permanent NAS UE ldentity=234150123451234,

Cause=“Relocation Triggered”, CN Domain lndicator=“CS Domain”, Source RNC

To Target RNC Transparent Container”

Algunos de los campos incluidos se enumeran en el ejemplo anterior, aunque esta lista no es exhaustiva.

La P- indica que es una extensión privada para las cabeceras de los mensajes SIP. En la práctica, suponiendo que el mensaje recibe aprobación dentro de la comunidad SIP para su inclusión en la especificación SIP genérica, la P no sería necesaria.

El contenido de esta nueva cabecera comprende la información requerida para el mensaje de solicitud Preparar Traspaso MAP que se envía en el siguiente paso desde el MSC_A al MSC_B. Esta información incluye la información del protocolo RANAP definida en la especificación TS25.413, esto es, parámetros de seguridad tales como contadores y claves, información de configuración de RAB, la identidad del RNC de destino y la configuración del protocolo MAP definida en la especificación TS29.002. La identidad del RNC de destino se conoce por el UE a partir de las mediciones que hizo de las celdas colindantes y pasó al LNN en el mensaje de informe de medición. La identidad de la celda de destino es normalmente un número de 28 bits compuesto por una identidad de RNC de 12 bits y una identidad de celda de 16 bits.

Para implementaciones de la Versión 5, el traspaso se implementa usando una reselección de celda seguida de una transferencia de sesión SIP.

3. El mensaje REFERIR se recibe por el SIP/MSC_A desde el LNN y se convierte a la solicitud de Preparar Traspaso MAP del mensaje de traspaso inter-MSC normal. Este mensaje se pasa al MSC_B.

4. El MSC_B envía entonces el mensaje 'Solicitud de Reubicación' al nuevo RNC_B, que configurará la macro celda para que el UE establezca una nueva conexión de llamada a través de la macro red externa.

5. Cuando el RNC ha completado la configuración, se envía el 'Acuse de Recibo de Solicitud de Reubicación' desde el RNC_B al MSC_B.

6. El MSC_B envía el 'Respuesta a Preparar Traspaso MAP' al MSC_A y en 7 el MSC_A responde con el '202 Aceptado' al LNN 40 indicando que la reubicación está procediendo correctamente;

8. A continuación, el LNN envía el mensaje RECONFIGURACIÓN DE CANAL FÍSICO al UE 4. Este mensaje se usa para realizar un traspaso fuerte entre dos celdas, en este caso, entre el LNN 40 y la celda controlada por el RNC_B.

9. Según la información especificada en el mensaje RECONFIGURACIÓN DE CANAL FÍSICO, el UE cambia a una frecuencia diferente y/o un código de aleatorización diferente para acceder a la nueva celda. Cuando el UE ha adquirido la nueva celda, se envía el mensaje RECONFIGURA^c I^ó N DE CANAL FÍSICO COMPLETA desde el UE al nuevo RNC_B a través del Nodo B 6 y la nueva macro celda.

10. El RNC_B a la detección del UE envía el mensaje 'Detección de Reubicación' al MSC_B.

11. El MSC_B envía entonces el mensaje Solicitud de Señal de Acceso de Proceso MAP al MSC_A.

12. El MSC_A envía la NOTIFICACIÓN SIP al LNN indicando que la reubicación fue un éxito, y el LNN responde en 13 con un 200 Ok.

14. El mensaje Reubicación Completa se envía por el RNC_B al MSC_B cuando se termina la reubicación.

15. El MSC_B envía la Solicitud de Señal de Fin de Envío MAP al MSC_A, que a su vez 16 envía el mensaje 'ADIOS' al LNN que termina la sesión SIP con el UE.

17. El LNN acusa recibo con el 200 Ok, y la llamada continúa a través del MSC_B y a través del MSC_A que actúa como MSC de Anclaje para la llamada. El MSC_A estará presente hasta que se abandone la llamada.

18. Cuando se completa la llamada, el MSC_A envía la respuesta de Señal de Fin de Envío MAP.

De este modo, se ha descrito un procedimiento en el que la transferencia de llamada y de conexión se puede lograr entre el LNN y una red externa, y en el que el mecanismo que se usa para la transferencia de conexión es consistente con el protocolo SIP. Los contenidos de los mensajes que se transportan a través del protocolo SIP también son consistentes con los mensajes que se transportan entre elementos de la red central para una reubicación de SRNS inter-MSC, los mensajes de la cual se definen en las especificaciones TS25.413, TS23.009 y TS29.002.

Identificación de LNN y control de potencia

Un aspecto del despliegue de un LNN que puede plantear una preocupación con los operadores que poseen el espectro en el que se desplegará el LNN es los niveles de interferencia que el LNN puede aportar a la macro red superpuesta. Los LNN tenderán a ser desplegados de una manera ad hoc con un control de operador limitado de la localización y las características del LNN. Por lo tanto, hemos apreciado que sería ventajoso si el operador fuera capaz de tomar un mayor control del método de despliegue del LNN con el fin de minimizar la interferencia.

La realización preferida aborda los problemas de la gestión de interferencias añadiendo elementos adicionales a los mensajes SIP que pasan entre el LNN y la red central del operador (o bien el MSC habilitado para SIP o bien la S-CSCF de la Versión 5). Esto se puede implementar en uno de dos mecanismos. Primero añadiendo una nueva cabecera SIP o alternativamente “canibalizando” una cabecera SIP existente. Se considerarán ambos aspectos. En esta realización consideraremos un ejemplo de la aplicación de la invención a una PLMN que se define según las especificaciones del 3GPP. Existen otros tipos de PLMN y a los que se aplicaría esta invención, las diferencias están en los nombres aplicados a los mensajes, no en los principios que se encuentran detrás de la transferencia de los mensajes.

Todos los mensajes SIP que se pasan entre clientes SIP, tales como el LNN y el MSC_A/SIP, contienen una cabecera SIP a la que se hace referencia como ID de Llamada. Esto se define en el estándar SIP [RFC3261] que expresa: “... el campo de cabecera de ID de Llamada debe ser seleccionado por el Cliente de Agente de Usuario (UAC) como un identificador único global sobre el espacio y el tiempo, a menos que se invalide por el comportamiento específico del método.”

En la realización preferida del sistema, la estructura de partes específicas del identificador de ID de Llamada para el LNN se definirá específicamente de manera que contenga información útil adicional. La información que se pasa a la red central en la cabecera SIP incluye preferiblemente al menos: el número de casa y el código postal (o información equivalente en diferentes ubicaciones geográficas); la potencia de transmisión actual (promedio) del LNN; el código de aleatorización del LNN; la ID de Celda, la potencia de transmisión y el tiempo.

Por lo tanto, la estructura de la ID de Llamada comprende una serie de campos, que describen las características del LNN, tales como la localización física y la designación de celda lógica, y que juntas dan como resultado un identificador único. Preferiblemente, se usan todos los campos siguientes, aunque se podrían incluir más o menos si se especifica por el operador de la red.

<Número de casa de la ubicación del LNN> <Código postal / ZIP de la ubicación del LNN> <id de código de aleatorización> <id de celda> <Potencia de transmisión> <Hora (formato UTC)>

El código postal y la información del número de casa se podrían obtener del usuario del LNN a través de un procedimiento de registro antes de que el LNN se haga operativo en la red. Alternativamente, el operador sabrá a qué Multiplexores de Acceso de Línea de Abonado Digital (DSLAM) está conectado un usuario y las áreas de código postal servidas por ese DSLAM.

Esta información se podría incluir en el mensaje como texto plano, o después de aplicar un algoritmo de cifrado adecuado. Las ocasiones cuando se transmitirá esta información incluirán, pero no se limitan a, el registro SIP del LNN, la iniciación de sesión SIP y la modificación del LNN.

Alternativamente, en lugar de configurar la ID de Llamada de la manera descrita anteriormente, se podría producir una nueva cabecera SIP que contenga la misma información. Preferiblemente, la nueva cabecera SIP se identificaría como:

Información de conexión P-LNN: <Número de casa> <Código postal / ZIP> <id de código de aleatorización> <id de celda> <Potencia de transmisión> <Hora (formato UTC)>

En una red típica, el operador registra todos los mensajes de señalización que se transfieren entre entidades. En una red que comprende el LNN y los mensajes modificados, un registro, por lo tanto, estará compuesto de mensajes entre el LNN y la red central. Éste se puede consultar por el operador, o bien leyendo el texto plano, o bien el texto después del descifrado, para identificar los LNN individuales y su potencia de transmisión.

De este modo, se ha propuesto un sistema en el que el operador puede monitorizar ahora la localización, los niveles de potencia y las características de los LNN que están presentes dentro de la red. Si el operador detecta que hay una caída en el rendimiento de la macro red, el operador puede examinar los registros almacenados de los mensajes de LNN e identificar las causas potenciales de esa interferencia en base al nivel de energía y la localización. Usando el sistema de Operación y Mantenimiento O y M, el operador será capaz de ajustar la potencia máxima de salida del LNN, o ajustar el código de aleatorización para superar los efectos de esta interferencia.

Haciéndolo así, el operador es capaz de predecir y controlar con más precisión los niveles de interferencia dentro de la red en la que hay un número de LNN desplegados.

Aunque la descripción anterior supone que se modifica la cabecera SIP de la ID de Llamada, o que se añade una nueva cabecera SIP, tales modificaciones también se aplican preferiblemente a las cabeceras SDP de la misma forma.

Configuración del sistema de comunicación

Con el fin de que el LNN opere correctamente, es necesaria la configuración del dispositivo. Aunque se puede proporcionar una interfaz de usuario en el LNN que permita que los ajustes de configuración sean seleccionados, da como resultado un aumento el tamaño y la complejidad del LNN en sí mismo lo que es indeseable. Por lo tanto, hemos apreciado que es deseable un método de configuración simplificado.

Por lo tanto, preferiblemente el LNN recibe información de configuración de una aplicación que se ejecuta en un terminal de usuario situado en el área de cobertura del LNN. El UE 4 en la Figura 2 puede estar ejecutando, por lo tanto, tal aplicación en una interfaz de usuario. La aplicación puede basarse en cualquier tecnología adecuada, tal como WMLScript, Java o el Juego de Herramientas de Aplicación USIM.

La aplicación está dispuesta para recopilar información del usuario que concierne a la configuración del LNN, o, alternativamente, solicitar datos de configuración del LNN para mostrarlos al usuario en su UE. La implementación de tales programas para los UE es conocida y no necesita ser descrita aquí más. Los datos de configuración que se pueden intercambiar entre el UE y el LNN comprenden preferiblemente información que especifica:

i) Los métodos de control que se pueden usar para permitir que UE adicionales sean añadidos a aquellos a los que se les permite acceder al LNN;

ii) Métodos para modificar datos para cualquier UE existente que esté registrado en el LNN; esto puede incluir la eliminación de los UE de una lista de acceso;

iii) El almacenamiento de mensajes SMS a ser entregados a uno de los otros UE registrados cuando llegan a estar activos dentro del área de configuración del LNN;

iv) El almacenamiento de los mensajes SMS a ser entregados en fechas y horas específicas a UE específicos registrados en el LNN;

v) El control de los perfiles de acceso de otros UE que acceden al LNN. Tales elementos pueden incluir el número de minutos llamados y los números de destino permitidos; y

vi) Qué UE tienen autorización para suministrar datos de configuración al LNN.

Cuando los datos de configuración adecuados se recopilan desde el usuario, el UE puede reenviar los datos de configuración a la función de control dentro del LNN. La función de control entonces actualiza una base de datos de configuración que puede ser parte del registro del LNN o separada de él.

Preferiblemente, los UE que están autorizados para obtener o transmitir datos de configuración usan un código PIN simple. El LNN se configura con un código de seguridad alfanumérico de 16 dígitos, y este código de seguridad se introduce en el UE en respuesta a una solicitud de la aplicación. El código PIN se usa entonces en cada intercambio de mensajes para asegurar que la solicitud está viniendo de un UE válido al LNN y también a la inversa.

La transmisión de datos entre el UE y el LNN se puede lograr a través del uso de una conexión SMS, una conexión de datos PS o una conexión de datos CS. El mecanismo específico puede ser seleccionable, por preferencia, por el usuario. Si se utilizan los canales datos de CS y los de datos de PS, entonces esta información puede ser enviada además sobre una conexión cifrada entre el UE y el LNN.

De este modo, un UE se usa para actuar como la interfaz de configuración para el LNN. Haciéndolo así, es posible la simplificación del diseño de la interfaz de usuario en el LNN, dando como resultado una reducción del coste y un aumento de la flexibilidad del diseño.

La descripción anterior no se pretende que sea limitativa, y se les ocurrirán una serie de modificaciones a los expertos dentro del alcance de las reivindicaciones. Por ejemplo, aunque se ha descrito SIP, se pueden usar otros protocolos, o pueden evolucionar, para la conexión a una red compatible con Internet. SIP se favorece actualmente, ya que simplifica enormemente la transmisión a través de la red compatible con Internet. No obstante, también se podrían usar otros esquemas tales como H.323 y H.324.

Además, aunque se ha descrito un sistema 3G, el LNN se puede implementar en sistemas 2G. Las redes compatibles con Internet podrían ser cualquiera de GSM, PSTN, PBX, PABX, CDMA 2000, WiFi modificada para incluir una entidad SIP o equivalente. Aunque ASDL también se ha implementado en la capa Física, también se pueden usar xDSL, SDSL, VSDL y equivalentes, tales como WIMAX.

Claims (19)

REIVINDICACIONES

1. Un nodo de red local, LNN, para transmitir mensajes entre un Equipo de Usuario, UE y una red compatible con Internet, el LNN que tiene una celda de cobertura en la que están situados uno o más UE, el LNN que comprende: una antena para transmitir señales a y recibir señales desde el UE, según un protocolo de radio celular; una conexión para transmitir mensajes a y recibir mensajes desde una red compatible con Internet; medios de conversión para convertir un mensaje entre el protocolo celular de radio y un protocolo de Internet de la red compatible con Internet caracterizado por que el LNN comprende además:

una base de datos en la que se almacena un estado de cada UE de abonado en el área de cobertura del LNN, cada estado que indica un punto en el protocolo celular de radio o el protocolo de Internet que ha alcanzado un UE de abonado; en donde el LNN está configurado para determinar, para cada UE de abonado, qué mensaje en qué protocolo se requiere a continuación en una secuencia predeterminada para que una conexión sea establecida o para que la comunicación continúe, sabiendo qué mensaje se requiere a continuación en cada caso, la traducción de dicho mensaje siguiente se configura para que ocurra extrayendo los datos pertinentes a partir de un mensaje en un formato de protocolo y usando los datos extraídos para rellenar los campos pertinentes en un mensaje del otro formato de protocolo.

2. El LNN de la reivindicación 1, en donde los medios de conversión comprenden una primera pila de procesamiento para procesar las señales según un protocolo celular de radio, la primera pila de procesamiento que tiene una funcionalidad correspondiente a las capas uno a tres del modelo de Interconexión de Sistemas Abiertos.

3. El LNN de la reivindicación 2, en donde la primera pila de procesamiento comprende:

i) una capa física,

ii) una capa de Control de Acceso al Medio;

iii) una capa de Control de Enlace de Radio; y

iv) una capa de Control de Recursos de Radio.

4. El LNN de la reivindicación 3, en donde la Capa de Recursos de Radio comprende la función de Portador de Acceso de Radio (RAB) y la función de Estrato sin Acceso (NAS) de Capa 3.

5. El LNN de cualquiera de las reivindicaciones 2 a 4, que comprende una segunda pila de procesamiento para procesar señales según un Protocolo de Internet, en donde la capa superior de la segunda pila de procesamiento está dispuesta para comunicarse con la capa superior de la primera pila de procesamiento.

6. El LNN de la reivindicación 5, en donde la segunda pila de procesamiento comprende una capa de procesamiento del Protocolo de Iniciación de Sesión (SIP).

7. El LNN de la reivindicación 6, en donde la conexión está dispuesta para su conexión a un MSC habilitado para SIP en la Versión 99 o arquitecturas UMTS posteriores.

8. El LNN de cualquier reivindicación precedente, en donde la conexión está dispuesta para su conexión a la Función de Control de Sesión de Llamada de la Versión 5 o arquitecturas UMTS posteriores.

9. El LNN de cualquier reivindicación precedente, en donde el LNN es operable para:

i) solicitar información de identidad que comprenda al menos la Identidad Internacional de Abonado Móvil (IMSI) de un UE que intenta registrarse en la red a través del LNN;

ii) incluir la información de identidad en un mensaje Registro de Protocolo de Internet (IP) para registrar el UE en la red;

iii) transmitir el mensaje de registro de IP a la red habilitada para el Protocolo de Internet;

iv) recibir los parámetros de seguridad de la red con relación al UE;

v) transmitir los parámetros de seguridad al UE a través de un mensaje de protocolo celular de radio;

vi) recibir una respuesta del UE y convertir ésta en un mensaje de protocolo de Internet que incluye los parámetros de seguridad además de la respuesta, de manera que la red pueda validar la autenticidad del Ue y completar el registro en la red.

10. El LNN de la reivindicación 9, en donde el mensaje de protocolo de Internet en el paso ii) iii) o vi) es un mensaje REGISTRO SIP.

11. El LNN de la reivindicación 9 o 10, en donde los parámetros de seguridad se reciben de la red mediante el mensaje de protocolo de Internet '401 No autorizado'.

12. El LNN de cualquier reivindicación precedente que comprende una base de datos de los UE que están autorizados a acceder a la red habilitada para SIP usando el LNN.

13. El LNN de la reivindicación 12, que comprende un módulo de control que está dispuesto para solicitar información de identidad que describe el UE, cuando el UE hace una solicitud de Actualización de Localización al LNN.

14. El LNN de la reivindicación 13, en donde la información de identidad es una o más de la Identidad Internacional de Abonado Móvil (IMSI) y la Identidad Internacional de Equipo Móvil (IMEI).

15. El LNN de la reivindicación 14, en donde el LNN es operable para almacenar la información de identidad en la base de datos.

16. El LNN de la reivindicación 13, en donde el LNN es operable para determinar a partir de la base de datos si un UE identificado por la información de identidad está autorizado, cuando el UE hace una solicitud de actualización de localización, y para denegar la solicitud si el UE no está autorizado.

17. El LNN de la reivindicación 16, en donde si se encuentra que el UE está autorizado, el LNN es operable para enviar los mensajes de registro de red recibidos desde el UE a la red habilitada para SIP.

18. El LNN de reivindicaciones 12 a 17, en donde el registro está dispuesto para almacenar información de uso con respecto a cada UE autorizado.

19. El LNN de la reivindicación 18, en donde se puede designar un UE maestro como que tiene acceso a la base de datos, y la capacidad de editar la información de uso para controlar el acceso permitido a los otros UE autorizados.