ES2370116T3

ES2370116T3 - Mensajes para interoperar entre una red de acceso móvil sin licencia y una red gprs para servicios de datos.

Info

Publication number: ES2370116T3
Application number: ES05747754T
Authority: ES
Inventors: Milan Markovic; Jianxiong Shi; Michael D. Gallagher; Rajeev Gupta
Original assignee: Kineto Wireless Inc
Current assignee: Kineto Wireless Inc
Priority date: 2004-05-14
Filing date: 2005-05-13
Publication date: 2011-12-12
Anticipated expiration: 2025-05-13

Abstract

Un método para facilitar servicios de datos para una estación móvil, MS, (102) en una red de acceso móvil sin licencia, UMAN, siendo dicha estación móvil operable en la UMAN y en una red inalámbrica de licencia y abarcando el método: - establecer una conexión dedicada entre el MS y la UMAN a través de un controlador de red (UNC) de acceso móvil sin licencia (UMA); - establecer una sesión de protocolo de control de transmisión, TCP, entre la MS y el UNC (paso A); - enviar mensajes UMA de control de radioenlace, URLC, entre la MS y el UNC para facilitar servicios de datos (pasos B y C), incluyendo cada mensaje URLC - un diferenciador de protocolo (1400); - un indicador de salto y - un tipo de mensaje a través del cual el mensaje correspondiente se puede identificar (1400) y transferir señales de servicio general de paquetes vía radio, GPRS, o de servicio de mensajes cortos, SMS, entre la MS y el UNC usando un mensaje URLC-DATA, incluyendo el mensaje URLC DATA (1400) una unidad de control de enlace lógico para paquetes de datos, LLC PDU, que contiene los datos a transferir.

Description

Mensajes para interoperar entre una red de acceso móvil sin licencia y una red gprs para servicios de datos

REFERENCIA CRUZADA A SOLICITUDES DE PATENTE RELACIONADAS

[0001] Esta solicitud también está relacionada con la publicación nº. US 2003-0119489 A1, actualmente la patente estadounidense nº US6,922,559, titulada "Unlicensed Wireless Communications Base Station to Facilitate Unlicensed and Licensed Wireless Communications with a Subscriber Device, and Method of Operation," con fecha de entrega del expediente de 2/04/2002; y la publicación nº US 2004-0192211 A1, actualmente la patente estadounidense US7.309.263, titulada "Apparatus for Supporting the Handover of a Telecommunication Session between a Licensed Wireless System and an Unlicensed Wireless System," con fecha de entrega del expediente de 20/09/2002. Ambas publicaciones estadounidenses US2003-0119489A1 US7.308.263 divulgan un sistema de comunicaciones que incluye un controlador de red que conecta comunicativamente este sistema de comunicaciones a un sistema de comunicaciones inalámbrico de licencia.

CAMPO DE LA INVENCIÓN

[0002] El campo de la invención se relaciona de modo general con las telecomunicaciones. Más específicamente, esta invención se refiere a un sistema de mensajería empleado en un sistema de telecomunicaciones de acceso móvil sin licencia (UMA por sus siglas inglesas en lo sucesivo) que incluye tanto infraestructura de radio con licencia como infraestructura sin licencia.

ANTECEDENTES DE LA INVENCIÓN

[0003] Los sistemas inalámbricos de licencia ofrecen comunicaciones inalámbricas móviles a usuarios que utilizan transceptores inalámbricos. Los sistemas inalámbricos de licencia se refieren a sistemas públicos de telefonía celular y/o sistemas de telefonía para servicios de comunicación personal (PCS). Los transceptores inalámbricos incluyen teléfonos móviles, teléfonos PCS, PDAs con capacidad inalámbrica, módems inalámbricos y similares.

[0004] Los sistemas inalámbricos de licencia utilizan frecuencias de señal inalámbrica cuya licencia se obtiene de los respectivos gobiernos. La cuantía de las tasas pagadas por el acceso a estas frecuencias es muy alta. Para apoyar las comunicaciones en sistemas de frecuencias sujetas a licencia se usan costosos equipamientos de estación base (BS por sus siglas inglesas en lo sucesivo). Tales estaciones base se instalan alrededor de a una milla de distancia la una de la otra (por ejemplo, los mástiles de móviles en una red para móviles). Los mecanismos de transporte inalámbrico y las frecuencias empleadas por los sistemas inalámbricos de licencia comunes limitan las tasas de transferencia de datos y el alcance. Como resultado, la calidad del servicio (calidad de voz y la velocidad de transferencia de datos) en los sistemas inalámbricos de licencia es considerablemente inferior a la calidad del servicio que ofrece la telefonía fija (con cable) por conexiones de línea terrestres. Por tanto el usuario de un sistema inalámbrico de licencia paga tarifas relativamente altas para un servicio de una calidad relativamente baja.

[0005] Las conexiones de línea terrestre (por cable) se encuentran desplegadas a gran escala y, en general, rinden a menor costo, ofreciendo una calidad de voz superior y servicios de datos de mayor velocidad. El problema con las conexiones de línea terrestre es que limitan la movilidad del usuario. Tradicionalmente, una conexión física a la telefonía terrestre es necesaria para tal servicio.

[0006] En los últimos años, el uso de los sistemas de comunicación inalámbrica sin licencia para facilitar el acceso móvil a redes terrestres ha experimentado un rápido crecimiento. Por ejemplo, tales sistemas inalámbricos sin licencia pueden apoyar la comunicación inalámbrica basada en los estándares IEEE 802,11a, b o g (WiFi), o en el estándar Bluetooth™. El margen de movilidad asociado a estos sistemas es típicamente del orden de 100 metros o menos. Un sistema típico de comunicación inalámbrica sin licencia suele estar formado por una estación base que comprende un punto de acceso inalámbrico (WAP) con una conexión física (por ejemplo mediante cable coaxial, de par trenzado, o cable de fibra óptica) a una red terrestre fija. El AP tiene un transceptor de radiofrecuencia para facilitar la comunicación con un teléfono inalámbrico que opera dentro de una distancia moderada del AP, donde las tasas de transporte de datos soportados por los estándares WiFi y Bluetooth ™ son muy superiores a los admitidos por los citados sistemas inalámbricos con licencia. Por lo tanto, esta opción ofrece servicios de mayor calidad a menor costo, pero los servicios sólo se pueden ofrecer dentro de una distancia moderada de la estación base.

[0007] En la actualidad, la tecnología está siendo desarrollada para integrar el uso de sistemas inalámbricos con y sin licencia sin incompatibilidades, permitiendo al usuario acceder a través de un solo terminal a un sistema inalámbrico sin licencia cuando se encuentra dentro del rango de este sistema, y acceder por otro lado al sistema inalámbrico con licencia cuando está fuera del alcance del sistema inalámbrico sin licencia, dirigiéndosele al controlador de red adecuado.

[0008] El documento WO 2004/034219 A (INTERDIGITAL TECHNOLOGY CORPORATION) con fecha de 22 de abril de 2004, divulga un método y sistema para proporcionar cobertura universal y conectividad sin fisuras a dispositivos que soportan al acceso a internet mediante tecnologías celulares (3G) y de red local de banda ancha IEEE 802.11 (WLAN) independientemente de la tecnología de radio acceso que esté disponible.

[0009] El documento WO2004/039111A, (AT & T Wireless Services, INC), con fecha de 6 de mayo de 2004, describe un sistema y un método para permitir que una estación de telefonía móvil o celular pueda interactuar con un teléfono móvil / servicio de datos, incluidos los sistemas convencionales 2G y 3G (en lo sucesivo "la red inalámbrica"), siendo también posible interactuar con los servicios de área locales, tales como WLAN, Bluetooth y redes de área personal, así como también comunicarse y usar tanto sistemas como periféricos disponibles dentro de dichas redes. Debido a que la estación móvil es un dispositivo autentificado en la red inalámbrica, dicha estación móvil también actúa como pasarela de enlace para permitir que otros servicios de área local y dispositivos puedan conectarse y comunicarse con la red inalámbrica.

[0010] El documento titulado "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (3GPP TS 24.008 version 5.6.0 Release 5); ETSI TS 124 008" especifica los procedimientos utilizados en los protocolos de núcleo de red de la interfaz de radio dentro de sistemas de telecomunicaciones móviles y de sistemas de telecomunicaciones digitales celulares de 3ª generación. Dicho documento especifica los procedimientos utilizados en la interfaz de radio (punto de referencia "Um" o "Uu", véase 3GPP TS 24.002 o 3GPP TS 23.002) para el control de llamadas (CC), Gestión de la Movilidad (MM), y la administración de sesiones (SM) (todas ellas por sus siglas inglesas en lo sucesivo). Estos procedimientos se definen en términos de mensajes intercambiados en canales de control de la interfaz de radio.

[0011] Para poder fomentar su implementación más rápida por parte de los fabricantes es necesario un conjunto estandarizado de mensajes para realizar diversas funciones, tales como el registro, la activación del canal, la entrega y similares.

RESUMEN DE LA INVENCIÓN

[0012] De acuerdo a aspectos de la presente invención se divulgan métodos para realizar varias operaciones usando mensajes de radiocontrol de enlace (URLC) de acceso móvil sin licencia (UMA) en una red de acceso móvil sin licencia (UMAN). La red UMAN abarca una primera red de radioacceso que se puede emplear para acceder a los servicios de datos por un núcleo de red que contiene una segunda red de radioacceso. Los mensajes URLC se intercambian entre las estaciones móviles (MSs) y los controladores de red UMA (UNCs) para realizar varias operaciones relacionadas con la UMAN. Utilizando un enlace inalámbrico usando una radiofrecuencia sin licencia, como enlaces 802.11 o Bluetooth™, la estación móvil MS puede acceder a la red UMAN a través de un punto de acceso inalámbrico (AP) que está conectado comunicativamente al controlador UNC mediante la red IP. Los mensajes URLC son enviados entre la estación MS y el controlador UNC usando una interfaz ascendente que abarca protocolos en capa sobre una capa de transporte IP subyacente.

[0013] De acuerdo a otro aspecto de la presente invención se divulgan mensajes URLC con formatos específicos. Estos mensajes incluyen un mensaje URLC-DATA. Cada uno de los mensajes URLC-DATA incluye un conjunto básico de elementos de información (IEs), incluyendo un discriminador de protocolo y un tipo de mensaje a través del cual puede identificarse el mensaje. También se divulgan IEs relevantes para el mensaje URLC-DATA

[0014] A continuación se divulga un método para proporcionar servicios de datos para una estación móvil (MS) dentro de una red de acceso móvil sin licencia. La MS puede operar con la red UMAN y con la red inalámbrica de licencia. El método establece una conexión dedicada entre la MS y la red UMAN a través de un controlador de red (UNC) de acceso móvil sin licencia (UMA). De acuerdo al método se establece una sesión de protocolo de control de transmisión entre la MS y el UNC. Según el método se envían mensajes de radiocontrol de enlace en UMA (URLC) entre la MS y el UNC para facilitar servicios de datos. Cada mensaje URLC incluye un discriminador de protocolo, un indicador de salto y un tipo de mensaje a través del cual puede identificarse el mensaje. El método transfiere las señales de servicio general de paquetes vía radio (GPRS) o servicios de mensajes cortos (SMS) entre la MS y el UNC usando un mensaje URLC DATA. El mensaje URLC DATA incluye una unidad de control de enlace de paquetes de datos (LLC PDU) que incluye los datos a transferir.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

[0015] Los aspectos anteriores y muchas de las ventajas acompañantes de esta invención podrán apreciarse y entenderse más fácilmente gracias a la referencia a la descripción detallada que sigue, especialmente cuando se aprecia en conjunción con las figuras adjuntas, en las que los números se refieren a partes concretas como se detalla en las vistas que siguen posteriormente y a menos que se especifique lo contrario:

[0016] La figura 1A proporciona una visión general de la solución de servicios móviles en una red de acceso interior (RAI) de acuerdo con una realización de la presente invención;

[0017] La figura 1B muestra las capas de protocolo GPRS de un conjunto móvil de acuerdo con una realización;

[0018] la figura 1C ilustra un método de conversión de protocolos de acuerdo con una realización;

[0019] la figura 2A muestra una visión general de una arquitectura de protocolo GPRS de nivel 1, nivel 2 y nivel 3 para una realización de una estación móvil que ofrece enlaces de radio sin licencia a través de señales Bluetooth; [0020] la figura 2B muestra una visión general de una arquitectura de protocolo GPRS de nivel 1, nivel 2 y nivel 3

para una realización de una estación móvil que ofrece enlaces de radio mediante señales IEEE 802.11

[0021] la figura 3A ilustra la arquitectura de protocolo ascendente interactuando del plano de usuario en GPRS, de acuerdo con una realización; [0022] la figura 3B muestra capas inferiores Bluetooth empleadas en una estación móvil y en un punto de acceso

para facilitar las comunicaciones de la capa física;

[0023] la figura 3C muestra las capas inferiores 802.11 usadas por una estación móvil y un punto de acceso para facilitar las comunicaciones de la capa física; [0024] la figura 3D ilustra la arquitectura de protocolo ascendente apoyando señales GPRS, GPRS SMS y señales

UMA específicas para servicios de datos de acuerdo con una realización;

[0025] la figura 4 ilustra varios escenarios posibles de cobertura GSM/GPRS y UMA de acuerdo con una realización; [0026] la figura 5 es un diagrama esquemático ilustrando los estados URLC y comportamientos asociados de la

estación móvil;

[0027] la figura 6 es un diagrama esquemático ilustrando los estados URLC y comportamientos asociados de la UMAN; [0028] la figura 7a ilustra un intercambio de mensaje URLC iniciado a través de una estación móvil para activar un

canal de transporte URLC;

[0029] la figura 7B ilustra un intercambio de mensaje URLC iniciado a través de un UNC para activar un canal de transporte URLC; [0030] la figura 8 es una tabla ilustrando una realización de un formato de mensaje URLC-ACTIVATE-UTC-REQ ; [0031] la figura 9 es una tabla ilustrando una realización de un formato de mensaje URLC-ACTIVATE-UTC-ACK; [0032] la figura 10 muestra un ejemplo de tabla de consulta que contiene valores de causas URLC; [0033] la figura 11 ilustra un intercambio de mensaje URLC iniciado a través de una estación móvil para desactivar

un canal de transporte URLC;

[0034] la figura 12 es una tabla ilustrando una realización de un formato de mensaje URLC-DEACTIVATE-UTC- REQ; [0035] la figura 13 es una tabla ilustrando una realización de un formato de mensaje URLC-DEACTIVATE-UTC-

ACK;

[0036] la figura 14 ilustra el uso de mensajes URLC-DATA para transportar señales GPRS y mensajes GPRS SMS vía señales existentes UMA; [0037] la figura 15 es una tabla que ilustra una realización de un formato de mensaje URLC-DATA; [0038] la figura 16 ilustra el uso de un mensaje URLC-PS-PAGE para paginar la estación móvil a los servicios PS; [0039] la figura 17 es una tabla ilustrando una realización de un formato de mensaje URLC PS PAGE; [0040] la figura 18 ilustra el uso de un mensaje URLC-SUSPEND-REQ para iniciar la suspensión de los servicios

GPRS; [0041] la figura 19 es una tabla que ilustra una realización de un formato de mensaje URLC-SUSPEND-REQ; [0042] la figura 20 ilustra el uso de un mensaje URR-RELEASE en conexión con la reanudación de servicios GPRS

para una estación móvil;

[0043] la figura 21 es una tabla que ilustra una realización de un formato de mensaje URR RELEASE;

[0044] la figura 22 ilustra el uso de un mensaje URLC-DFC-REQ para iniciar el procedimiento de control de flujo en dirección al enlace descendente;

[0045] la figura 23 es una tabla que ilustra una realización de un formato de mensaje URLC-DFC-REQ;

[0046] la figura 24 ilustra el uso de un mensaje URLC-UFC-REQ para iniciar el procedimiento de control de flujo en dirección al enlace ascendente;

[0047] la figura 25 es una tabla que ilustra una realización de un formato de mensaje URLC-SUSPEND-REQ;

[0048] la figura 26 ilustra el uso de mensajes URLC-UNITDATA para transportar datos mediante una capa de transporte UDP;

[0049] la figura 27 es una tabla que ilustra una realización de un formato de mensaje URLC-UNITDATA;

[0050] la figura 28 es una tabla que ilustra una realización de un formato de mensaje URLC-STATUS;

[0051] la figura 29 es un diagrama esquemático de bloques que ilustra una realización de una arquitectura de alto nivel de un UNC, y

[0052] la figura 30 es un diagrama esquemático de bloques que ilustra una realización de una arquitectura de alto nivel de una estación móvil.

DESCRIPCIÓN DETALLADA

[0053] En la siguiente descripción, numerosos detalles específicos se aportan para proporcionar un conocimiento profundo de las realizaciones de la invención. El experto en la materia reconocerá no obstante que la invención se puede realizar sin uno o más de los detalles específicos, o con otros métodos, componentes, materiales etc. En otras circunstancias, los materiales, operaciones o estructuras de sobra conocidos no se muestran o describen para evitar oscurecer aspectos de la invención.

[0054] La referencia en esta especificación a "una realización" o "la realización" significa que alguna función, estructura u otra de las características descritas en relación con la realización se incluye en al menos una forma de realización de la presente invención. Por lo tanto, cuando aparece la frase "en una realización" o "en la realización" en varios pasajes a lo largo de esta especificación no se realiza necesariamente referencia a la misma realización. Además, las particularidades, estructuras, o características específicas de la presente invención se pueden combinar de manera adecuada en una o más realizaciones.

[0055] En la presente descripción, el sistema inalámbrico sin licencia puede ser un sistema inalámbrico de corto alcance, que puede ser descrito como una solución para recintos cerrados. Sin embargo, se entenderá a lo largo del presente documento que el sistema inalámbrico sin licencia incluye sistemas inalámbricos que cubren no sólo una parte de un edificio, sino también zonas locales al aire libre, tales como la parte exterior de un campus corporativo, en los que se presta un servicio mediante sistema inalámbrico sin licencia. El terminal móvil puede ser, por ejemplo, un teléfono móvil, un teléfono inteligente, un asistente personal digital o un ordenador portátil. El terminal móvil también puede ser, por ejemplo, un dispositivo inalámbrico fijo que proporciona un conjunto de funciones de adaptador de terminal para la conexión de red digital de servicios integrados (RDSI) o para terminales POTS (Plain Old Telephone Service) al sistema inalámbrico. La aplicación de la presente invención a este tipo de dispositivos permite que el proveedor de servicios inalámbricos pueda ofrecer los así denominados servicio de telefonía fija de reemplazo a los usuarios, incluso para las ubicaciones de los usuarios no suficientemente cubiertas por el sistema inalámbrico de licencia. La presente descripción se encuentra en el contexto de arquitecturas estandarizadas UMA (acceso móvil sin licencia) promulgadas por el consorcio UMA. Sin embargo, la invención no se limita únicamente a este contexto.

[0056] A lo largo de la siguiente descripción se utilizan acrónimos de uso común en la industria de las telecomunicaciones para referirse a servicios inalámbricos, junto con siglas específicas de la invención. Una tabla de abreviaturas relativas a la presente invención está incluida en el apéndice I.

[0057] La figura 1A ilustra una arquitectura de acceso móvil sin licencia (UMA) 100 de acuerdo con una realización de la presente invención. La arquitectura UMA 100 permite a un usuario de una estación móvil 102 acceder a una red de voz y de telecomunicaciones 104 a través de una sesión de comunicaciones inalámbricas con licencia 106 o de una sesión inalámbrica de comunicaciones sin licencia 108. La red de telecomunicaciones 104 incluye un centro de conmutación móvil (MSC) 110, que proporciona acceso a una red de voz 112, y a un nodo de servicio (SGSN) del servicio GPRS (General Packet Radio Service), que proporciona acceso a una red de datos 116. El MSC 110 también proporciona una función de registro interno de localización de visitantes (VLR).

[0058] De forma más detallada, la sesión de comunicación inalámbrica sujeta a licencia se facilita mediante una infraestructura aportada por una red inalámbrica de licencia 118 que incluye una red de telecomunicaciones 104. En la realización que se muestra en las figuras, la red inalámbrica de licencia 118 muestra componentes típicos de una red móvil de tipo GSM (Global System for Mobile Communications) que incluye múltiples estaciones transceptoras base (BTS) 120 (de las que se sólo se muestra una por razones de simplicidad), las cuales facilitan servicios de comunicación inalámbricos a varias estaciones móviles 102 a través de los enlaces de radio respectivos 122 de licencia (por ejemplo, enlaces de radio que emplean frecuencias de radio dentro de un ancho de banda sujeto a licencia). Por lo general, las múltiples BTS 120 se configuran en modo celular (una por cada celda) que cubre una amplia área de servicio. Los diversos BTSs 120 para una determinada zona o región son administrados por un controlador de estación base (BSC) 124, estando cada BTS 120 acoplado comunicativamente a su BSC 124 a través de un tramo privado 126. En general, una red grande inalámbrica con licencia, tales como las proporcionadas por un proveedor de servicios móviles a nivel nacional o regional, incluye múltiples BSC 124.

[0059] Cada BSC 124 comunica con la red de telecomunicaciones 104 a través de una interfaz de controlador de estación base estándar 126. Por ejemplo, un BSC 124 puede comunicarse con MSC 110 a través de la interfaz GSM-A para servicios de voz de circuito conmutado y con SGSN 114 a través de la interfaz GSM-Gb para servicios de paquetes de datos (GPRS). Las redes de voz convencional y de datos sujetas a licencia 104 incluyen protocolos para permitir transferencias sin interferencias de un BSC 124 asociado a otro BSC 124 (no se muestra).

[0060] Una sesión de comunicación sin licencia 108 se facilita a través de un punto de acceso (sin cable) (AP) 128 que comprende una estación base interior 130. Por lo general, el AP 128 se encuentra en una estructura fija, como una casa 132 o un edificio de oficinas 134. El área de servicio de la estación base de interiores 130 abarca una parte interior de un edificio, aunque se entiende que el área de servicio de una estación base en interiores puede incluir una porción exterior de un edificio o un campus. Según lo indicado por la flecha que representa la sesión de comunicación sin licencia 108, el terminal móvil 102 puede estar conectado a la red de telecomunicaciones 104 a través de una segunda línea de datos que incluye un canal inalámbrico sin licencia 136, un punto de acceso 128, una red de acceso 138, y un controlador de red (UNC) para acceso móvil sin licencia 140. El UNC 140 comunica con la red de telecomunicaciones 104 utilizando una interfaz de controlador de estación base 126B que es similar a la interfaz de controlador de la estación base 126A e incluye una interfaz GSM-A y una interfaz Gb. El punto de acceso 128 puede incluir entidades de software almacenadas en la memoria que se ejecutan en uno o varios microprocesadores (no se muestran en la figura 1A), adaptados para realizar la conversión de protocolo.

[0061] El canal móvil sin licencia 136 se facilita mediante un enlace de radio que utiliza una longitud de onda (o rango de onda) de un espectro sin licencia y libre (por ejemplo, el espectro en torno a 2,4 GHz, 5 GHz, 11-66 GHz). Un servicio de alojamiento sin licencia que aloja un canal inalámbrico sin licencia 136 puede tener asociado un protocolo de comunicación. Como ejemplos, el servicio inalámbrico sin licencia puede ser un servicio inalámbrico compatible con Bluetoothtm o un servicio de red inalámbrica de área local (LAN) (WiFi) (por ejemplo, el estándar inalámbrico IEEE 802,11a, b, o g). Esto proporciona al usuario una calidad de servicio potencialmente mejorada en regiones del servicio móvil sin licencia (es decir, dentro de la gama de servicios del correspondiente punto de acceso (AP)). Así, cuando un usuario abonado está dentro del alcance de la licencia del AP, dicho usuario abonado puede disfrutar de servicios de datos y voz a bajo coste, alta velocidad y alta calidad.

[0062] Además, el abonado disfruta de un rango extendido de servicio ya que el teléfono puede recibir servicios en lugares apartados del interior de un edificio, en los que de otro modo no se obtiene un servicio fiable por parte del sistema inalámbrico con licencia. Al mismo tiempo, el usuario abonado puede salir fuera del alcance del AP sin licencia sin perder la comunicación. En lugar de ello, el proceso de itinerancia fuera del alcance del AP de licencia se realiza mediante una entrega sin interferencias (también conocido como handoff), proporcionándose los servicios de comunicación automáticamente a través del sistema inalámbrico de licencia, como se describe con más detalle en la el documento de solicitud de patente US10/115833, cuyo contenido se incorpora al presente documento por referencia.

[0063] La estación móvil 102 puede incluir un microprocesador y una memoria (no se muestra) que almacena instrucciones de un programa de ordenador para la ejecución de protocolos inalámbricos para la gestión de las sesiones de comunicación. Como se ilustra en la figura 1B, una realización del terminal móvil 102 incluye una capa 1 de protocolo 142, una capa 2 de protocolo 144 y una capa 3 de protocolo de señalización para el servicio inalámbrico con licencia que incluye una subcapa de radiocontrol de enlace (RLC) 146, una subcapa de control lógico de enlace (LLC) 148, y una capa de gestión de llamadas (CM) 150. Se entenderá que las capas de nivel 1, nivel 2 y nivel 3 pueden implementarse como módulos de software, los cuales también puede describirse como "entidades" de software. De acuerdo con una nomenclatura común en servicios inalámbricos con licencia, la capa 1 es la capa física, es decir, la banda de base física para una sesión de comunicación inalámbrica. La capa física es la capa inferior de la interfaz de radio y proporciona funciones para la transferencia de flujos de bits a través de enlaces de radio físicos. La capa 2 es la capa de enlace de datos. La capa de enlace de datos proporciona las señales entre el terminal móvil y el controlador de estación base. La subcapa RLC se ocupa de la conexión de capa de enlace entre la MS y los UNC/BSS para prestar servicios de datos GPRS. La subcapa LLC 148 se usa para transportar información entre las entidades de la capa 3 en la MS y el SGSN para prestar servicios de datos GPRS. Las capas superiores 150 incluyen protocolos estándar de capa 3 y aplicaciones usadas para servicios de datos GPRS.

[0064] La estación móvil puede incluir también una capa física para un servicio móvil sin licencia 152 (es decir, una capa física para servicios móviles sin licencia, como Bluetooth, WiFi, o de otros canales sin licencia (por ejemplo, WiMAX). La estación móvil también incluye una capa 154 de enlace de nivel 2 de servicio inalámbrico sin licencia y una(s) subcapa(s) 156 RLC de servicio inalámbrico sin licencia. Un conmutador 160 de modo de acceso se incluye para el LLC148 y capas superiores 150 para acceder a la subcapa(s) 156 RLC de servicio inalámbrico sin licencia y a la capa de enlace de servicio inalámbrico sin licencia 154 cuando la estación móvil 102 está dentro del rango del AP sin licencia 128 y para apoyar el cambio de la subcapa RLC 146 de licencia y la subcapa RLC 156 sin licencia.

[0065] La subcapa RLC sin licencia 156 y la capa de enlace sin licencia 154 pueden incluir protocolos específicos para el servicio inalámbrico sin licencia utilizados además de determinados protocolos para facilitar la transferencia sin pérdidas entre los sistemas inalámbricos con y sin licencia. En consecuencia, la subcapa RLC sin licencia 156 y la capa de enlace sin licencia 154 deben ser convertidas a un formato compatible con el protocolo convencional de la interfaz de controlador de la estación base 126 para ser reconocidos por una red de datos MSC, SGSN u otro tipo de red.

[0066] En referencia a la figura 1C, en una realización de la presente invención, la estación móvil 102, el AP 128 y el UNC 140 proporcionan una función de conversión de interfaz para convertir las capas de nivel 1, nivel 2 y nivel 3 del servicio sin licencia a una interfaz convencional 126B de la subred de la estación base convencional subred (BSS) (por ejemplo, una interfaz-Gb). Como resultado de la conversión de protocolo, una sesión de comunicación se puede establecer que es transparente a la red de datos 104, es decir, la red de datos 104 utiliza la interfaz estándar y los protocolos para la sesión de comunicación como se haría con una sesión de comunicación convencional a cargo de una estación base transceptora convencional. Por ejemplo en algunas realizaciones, el terminal móvil 102 y el UNC 140 están configurados para iniciar y reenviar las solicitudes de servicio y de actualización de la localización. Como resultado se proporcionan protocolos para una transferencia de los servicios sin fisuras transparentes a la red de datos 104. Esto permite, por ejemplo, un único número de teléfono que se utilizará tanto para el servicio inalámbrico con licencia y para el servicio móvil sin licencia. Además, la presente invención permite el uso de una variedad de servicios mediante un servicio móvil sin licencia que tradicionalmente se ofrecían sólo a través de servicios inalámbricos con licencia. Así, el cliente obtiene el beneficio de una calidad de servicio potencialmente mayor cuando el terminal móvil se encuentra en el área un servicio inalámbrico sin licencia con gran ancho de banda, teniendo al mismo tiempo acceso a servicios telefónicos convencionales.

[0067] El servicio inalámbrico con licencia puede incluir cualquier servicio inalámbrico con licencia con un protocolo predefinido de interfaz BSS 126 para la red de voz y de datos 104. En una realización de la invención, el servicio inalámbrico con licencia es una red de acceso por radio GSM / GPRS, aunque se entenderá que la realización de la presente invención incluye otros servicios inalámbricos con licencia. Para esta realización, el UNC 140 interconecta a la red básica GSM a través de las mismas interfaces de controlador de estación base 126 utilizadas por un elemento de red BSS estándar GSM. Por ejemplo, en una aplicación de GSM, estas interfaces son la interfaz GSM-A para servicios de voz de circuito conmutado y la interfaz GSM Gb para servicios de paquetes de datos (GPRS). En una aplicación UMTS (Universal Mobile Telecommunications System) de la invención, el UNC 140 se conecta a la red UMTS mediante una interfaz Iu-cs UMTS para servicios de voz de circuito conmutado y una interfaz Iu-ps UMTS para servicios de paquetes de datos. En una aplicación CDMA de la invención, el UNC 140 interconecta con la red CDMA usando las interfaces CDMA A1 y A2 para servicios de voz de circuito conmutado y las interfaces CDM A10 y A11 para servicios de paquetes de datos.

[0068] En una realización de red GSM / GPRS, el UNC 140 se le muestra al núcleo de red GSM / GPRS como un elemento BSS de red GSM, gestionándose y operándose como tal. En esta arquitectura, los elementos principales del control de transferencias (por ejemplo, el procesamiento de llamadas) son proporcionados por elementos de la red superior, a saber, el registro de localización de visitante MSC 110 (VRL) y los SGSN 114. Las estaciones móviles tienen autorización de acceso a la red básica GSM / GPRS ya sea directamente a través de la red de acceso radio GSM si se encuentran fuera del área de servicio del punto de acceso 128, o a través del sistema de red UMA si se encuentran dentro del área de servicio de un AP.

[0069] Debido a que la sesión de comunicación portada por la arquitectura UMA 108 es transparente a la red de voz 112 o a la red de datos 116, el servicio inalámbrico sin licencia puede ser compatible con todos los servicios al usuario que ofrecen los proveedores de servicios inalámbricos. En el caso de haber recursos de sistema GSM disponibles, estos recursos normalmente proporcionan los siguientes servicios básicos de telefonía: Telefonía: Llamada de emergencia (por ejemplo, llamada E911 en América del Norte), mensajes de móvil terminados punto-apunto (MT/PP), mensajes de móvil originados punto-a-punto (MO / PP), servicios de portador GPRS y entrega (exterior a interior, interior a exterior, la voz, datos, SMS, SS). Además, el sistema GSM también podrá soportar varios servicios complementarios que son bien conocidos en este campo técnico.

[0070] La figura 2A proporciona una visión general de una arquitectura relacionada con el protocolo GPRS de nivel 1, nivel 2 y nivel 3 en una forma de realización del terminal móvil 102 que ofrece enlaces de radio sin licencia a través de señales de Bluetooth. Como se muestra, hay dos entidades de gestión del enlace de radio de control RLC: La entidad GSM RLC 202 y la entidad UMA-RLC 204. La arquitectura de protocolo incluye una capa 206 de nivel 1 de banda base GSM ; una capa 208 de enlace de nivel 2 GSM (LAPDm) ; una capa 210 de banda base de nivel 1 Bluetooth; capas 211 de nivel 2 de Bluetooth que incluyen una capa 212 de nivel 2 para procesos de establecimiento de conexión (L2CAP), una capa BNEP 213, un conmutador de modo de acceso 214 y protocolos de capa superior

216. Cuando el terminal móvil está funcionando en modo UMA, la entidad UMA-RLC 204 es la entidad actual RLC "sirviente", es decir, que presta el servicio a las capas superiores, incluyendo la subcapa GPRS de gestión de la movilidad (GMM) y la subcapa LLC a través de los puntos de servicio de acceso designados GMMRR-SAP y GRR-SAP. La entidad GSM RLC está separada de las subcapas GMM y LLC en este modo. La entidad UMA-RLC 204 proporciona un nuevo conjunto de funciones y es responsable de la emulación de la capa GSM RLC para proporcionar los servicios esperados a las capas GMM y LLC, es decir, transferencia de paquetes, suspensión GPRS, etc. Todos los operadores primitivos GSM 04.64 definidos para el GRR-SAP y GMMRR-SAP se aplican en este caso. El plug-in de la entidad UMA-RLC 204 se hace transparente a los protocolos de la capa superior de esta manera. Además un módulo de la entidad UMA-RLC 204 es responsable de la coordinación con la entidad GSM RLC para gestionar la conmutación del modo de acceso y el reenvío de paquetes, tal y como se describe en detalle en la solicitud con número de serie 10/688470 a la que se hace referencia más arriba.

[0071] La figura 2B proporciona una visión general de una arquitectura relacionada con el protocolo GPRS nivel 1, nivel 2 y nivel 3 en una forma de realización del terminal móvil 102 que ofrece enlaces de radio sin licencia a través de señales IEEE 802.11. Todas las entidades y las capas son las mismas que las descritas anteriormente para la figura 2A, excepto que las capas de Bluetooth se han sustituido por una capa 802.11 PHY 218 y una capa MAC

802.11 220.

[0072] La figura 3A ilustra la arquitectura de protocolo ascendente del plano de usuario en GPRS, de acuerdo con una realización. La arquitectura GPRS de protocolo simple de usuario permite un uso efectivo de túneles GPRS de paquetes de datos a través del UNC 140 utilizando el espectro libre de licencia y favoreciendo así una función de túnel para el tráfico de paquetes conmutados entre la estación móvil 102 y SGSN 118. Los protocolos UMA-RLC (URLC) apoyan las funciones de señalización UMA de "nivel 3" a través de las capas UMA-RLC 204 proporcionadas por cada estación móvil 102 y cada UNC 140. El UNC 140 actuando de BSC termina los mensajes de protocolo URLC y es responsable de que estos mensajes interoperen con los mensajes de interfaz análoga Gb.

[0073] Como se ilustra en la figura 3A, cada uno de los UNC 140 y SGSN 114 emplean medios convencionales para apoyar señales y paquetes de datos GPRS, incluyendo una capa física 300, una capa de servicios de red 302 y una capa BSSGP 304. Cada terminal móvil 102 y UNC 140 incluyen una capa UDP 306 y una capa UMA-RLC 204. Cada terminal móvil 102 y SGSN incluyen una capa LLC 216 y una capa SNDCP 308. El terminal móvil 102 también incluye una capa IP 310. Bajo la arquitectura de la figura 3ª, los PDUs compatibles con GPRS LLC que transportan datos se llevan de forma transparente entre la estación móvil 102 y el SGSN 114. Esto permite que la estación móvil derive todos los servicios GPRS de la misma manera que si fuera un BSS GERAN. Todas las aplicaciones GPRS existentes y las interfaces MMI en el terminal móvil 102 permanecen inalteradas. Los PDUs de datos de control de enlace lógico se transmiten mediante la capa UMA-RLC 204 del terminal móvil 102 al UNC 140, que los retransmite a cada SGSN 114 usando mensajería BSSGP. La capa UMA-RLC 204 para el transporte de datos se ejecuta directamente a través de la capa UDP 306 para potenciar el servicio portador de IP.

[0074] Las capas por debajo de la capa UMA-RLC 204 en cada terminal móvil 104 y UNC 140 incluyen una capa TCP 316, una capa IP remota 318 y una capa IPSec 320. Como opción, se puede utilizar el estándar Secure Socket Layer (SSL) a través de TCP/IP (no mostrado) en lugar de la capa IPSec 320.

[0075] La conectividad IP de bajo nivel entre el terminal móvil 102 y el UNC 140 se soporta mediante las capas apropiadas alojadas en un punto de acceso 128 y una red de banda ancha IP 138 (es decir, el acceso a la red 138 mostrado en la figura 1A).Los componentes de apoyo de la capa de transporte IP (es decir, la capa de red convencional 3 de acuerdo a las siete capas del modelo OSI) incluyen capas de transporte IP 322 para cada terminal móvil 104, AP 128 y para la red IP 138, así como una capa IP 322A en el UNC 140.

[0076] En las capas más bajas (es decir, las capas físicas y de enlace de datos), la estación móvil 104 y el AP 128 están representadas proporcionando capas inferiores sin licencia 324, cada una de los AP 128, la red IP 138, UNC 140 proporcionan capas adecuadas de acceso 326. Por lo general, las capas de acceso 326 incluirán capas convencionales Ethernet PHY y capas MAC (IEEE 802.3), aunque esto no es una condición limitante.

[0077] Como se muestra en las figuras 3B y 3C, las capas de las capas inferiores sin licencia 324 dependerán de si el enlace de radio sin licencia utiliza señalización Bluetooth o señalización IEEE 802.11. Las capas de Bluetooth inferiores que se muestran en la figura 3B corresponden a la arquitectura de la estación móvil de la figura 2A, e incluyen una capa de banda base Bluetooth 210, una capa L2CAP 212, y una capa BNEP 213. Mientras tanto, las capas inferiores 801.11 que se muestran en la figura 3C corresponden a la arquitectura de la estación móvil de la figura 2B e incluyen una capa PHY 802.11 218 y en 802.11 la capa MAC 220.

[0078] La figura 3D ilustra la arquitectura de protocolo ascendente soportando señales GPRS y servicios SMS, de acuerdo con una realización. Bajo esta arquitectura, los PDUs GPRS LLC para la señalización en protocolos de capas superiores (incluidas las capas superiores 328) se transportan de forma transparente entre cada terminal móvil 102 y SGSN 114. Esto permite que cada MS obtenga todos los servicios GPRS de la misma manera que si estuviera conectada a un servicio BSS GERAN. El protocolo GPRS-RLC se sustituye por un protocolo UMA-RLC equivalente (desde la perspectiva de la capa superior). La fiabilidad está garantizada por la capa TCP 330. Al igual que en un BSS GERAN, el UNC, actuando como un BSC, termina el protocolo UMA-RLC y lo interconecta a la interfaz Gb mediante BSSGP.

[0079] Como se señaló anteriormente, la estación móvil puede ser, por ejemplo, un teléfono móvil, un teléfono inteligente, un asistente digital personal o un ordenador móvil. La estación móvil también puede ser, por ejemplo, un dispositivo inalámbrico fijo que proporciona un conjunto de funciones de adaptador de terminal para la conexión de Red Digital de Servicios Integrados (RDSI) o terminales de línea telefónica convencional (POTS) al sistema inalámbrico.

[0080] Otros tipos de terminales adaptadores diferentes a los anteriormente mencionados se pueden emplear con las realizaciones de la invención. (1) un adaptador terminal compatible con teléfonos inalámbricos en lugar de teléfonos de red básica (POTS_RTB); (2) un adaptador terminal que soporta teléfonos basados en el estándar Session Initiation Protocol (SIP), y (3) un adaptador de terminal que también integra un teléfono con cable y una interfaz de usuario, como las que se puede encontrar en teléfonos de escritorio. En cada caso, la presente invención detalla cómo estas funciones de adaptador terminal se pueden conectar con el sistema inalámbrico a través de la red sin licencia.

[0081] El uso de otras capacidades estándar de Bluetooth, junto con las realizaciones de la invención también es posible. Por ejemplo, existe una funcionalidad estándar de Bluetooth llamada "perfil de acceso SIM" que permite a un dispositivo Bluetooth (por ejemplo, un subsistema de telefonía móvil integrado en un coche) acceder a la tarjeta SIM que está en otro dispositivo Bluetooth (por ejemplo, el teléfono móvil normal del usuario), permitiendo que el primer dispositivo asuma la identidad asociada a la tarjeta SIM, (es decir, la identidad del usuario del teléfono normal). Las realizaciones descritas anteriormente podrían hacer uso de esta capacidad estándar para dar a los dispositivos de terminal conectados al adaptador (por ejemplo, un teléfono POTS) la identidad del teléfono celular del usuario.

[0082] El UNC 140 proporciona funciones equivalentes a las de un BSC GSM y como tal controla una o más células (virtuales) de UMA. En una realización, puede haber una sola celda UMA por cada UNC y, en una realización alternativa, puede haber una celda UMA por cada punto de acceso conectado a un UNC. La realización mencionada por último puede ser menos deseable debido al gran número de puntos de acceso que sería necesario utilizar, por lo que la arquitectura UMA permite agrupaciones flexibles de los APs en las celdas UMA. Cada celda UMA puede estar identificada por un identificador global de celda (GCI), con un número de canal de frecuencia absoluta (ARFCN) fuera de uso que esté asignado a cada celda UMA. Cada celda UMA puede estar mapeada a un límite físico al asociarla con áreas específicas de ubicación GSM servidas por el MSC. Las celda GSM dentro de las zonas locales mapeadas a una celda UMA se configuran mediante asignaciones de ARFCN al CGI de esa celda UMA concreta. Además, este ARFCN podrá aparecer en las listas BA de las celdas GSM para permitir las entregas. Téngase en cuenta que las celdas UMA podrán utilizar los mismos identificadores de área de ubicación (LAI) que las celdas existentes GSM, o un nuevo LAI puede ser utilizado para las celdas UMA. Esto último es útil para la reducción de la paginación en celdas GSM cuando se sabe que una estación móvil está registrado a través de una INC. El planteamiento anterior se aplica igualmente a áreas de enrutamiento GPRS y a identificadores de área de enrutamiento (EFR).

DIRECCIONAMIENTO CPE de UMA

[0083] El equipo en las instalaciones del cliente (CPE) puede incluir el terminal móvil y el punto de acceso (AP) a través del cual el terminal móvil puede acceder al UNC para el servicio UMA. Los parámetros CPE para el direccionamiento UMA pueden incluir los parámetros descritos a continuación.

[0084] El direccionamiento UMA-CPE incluye la identidad internacional de abonado móvil (IMSI) asociada con la tarjeta SIM del equipo móvil como parámetro. La identidad IMSI la proporciona el terminal móvil en el sistema UMA al UNC, cuando se transmiten solicitudes de servicio UMA a través de la interfaz ascendente al UNC. A diferencia del BSC en sistemas GSM, el UNC gestiona un contexto para cada terminal móvil que está funcionando en modo UMA. Por lo tanto, el UNC mantiene un registro de cada terminal móvil al que presta servicio. Por ejemplo, la identidad IMSI podrá ser utilizada por el UNC para encontrar el registro adecuado de terminal móvil cuando el UNC recibe mensajes de paginación BSSMAP.

[0085] El direccionamiento CPE UMA incluye la dirección asociada con la interfaz sin licencia en el equipo móvil (por ejemplo, la dirección MAC 802.11) como parámetro. Este identificador puede ser proporcionado por el terminal móvil UMA al UNC, cuando este transmite solicitudes de servicio UMA a través de la interfaz ascendente. El UNC podrá utilizar esta dirección como una alternativa a la IMSI para limitar la transferencia de la IMSI a través de la interfaz ascendente para ayudar en el enrutamiento de mensajes.

[0086] El direccionamiento CPE UMA también incluye el identificador de enlace lógico temporal (TLLI) asignado como parámetro al terminal móvil por el nodo de apoyo GPRS (SGSN). Este identificador puede ser proporcionado a través de procedimientos estándar de interfaz Gb. El UNC sigue esta dirección para cada estación móvil para apoyar los procedimientos de la interfaz GSM-Gb (por ejemplo, de modo que los paquetes de enlace descendente GPRS se puedan enrutar al terminal móvil correcto).

[0087] El direccionamiento CPE UMA también incluye el identificador (ID) del punto de acceso (AP-ID) como parámetro. El AP-ID puede ser la dirección MAC del punto de modo de acceso sin licencia través del cual la estación móvil accede a servicios UMA. Este identificador puede ser proporcionado por el terminal móvil UMA al UNC, cuando este transmite solicitudes de servicio UMA a través de la interfaz ascendente. El AP-ID puede ser utilizado por el UNC para apoyar los servicios de localización (por ejemplo, el servicio 911 mejorado) para el usuario sobre la base del punto de acceso desde el que se accede al servicio. El AP-ID también puede ser utilizado por el proveedor de servicios para restringir el acceso de servicios UMA sólo a los puntos de acceso autorizados.

[0088] Otros parámetros de direccionamiento CPE a utilizar dependerán de los requisitos de seguridad de la interfaz ascendente (por ejemplo, la necesidad de gestionar las direcciones IP de terminales móviles UMA para el enrutamiento de mensajes a través de conexiones IPSec tuneladas o por la necesidad de gestionar credenciales locales asignadas al terminal móvil por el UNC).

IDENTIFICACIÓN DE CELDAS UMA

[0089] A fin de facilitar las funciones de gestión de la movilidad en las redes GSM/GPRS, el área de cobertura puede estar dividida en las áreas de registro lógico denominadas áreas de ubicación (para sistemas GSM) y áreas de enrutamiento (para sistemas GPRS). Las estaciones móviles pueden ser obligadas a registrarse en la red cada vez que el área de localización (o área de enrutamiento) se modifique. Uno o más identificadores de áreas de ubicación (LAIs) se pueden asociar a cada registro de localización visitado (VLR) del operador de red. Del mismo modo, uno o más identificadores de área de enrutamiento (RAIs) puede ser controlado por un solo SGSN.

[0090] En una realización, una celda GSM se identifica en el área de ubicación o de enrutamiento añadiendo una identidad de celda (CI) para la identificación de las áreas de ubicación o de enrutamiento. La identificación global de celda (CGI) es la unión de la de zona de localización y de la identidad de celda. En una realización, la identidad de celda es única dentro de una zona de ubicación.

UN EJEMPLO DE PLANTEAMIENTO PARA LA IDENTIFICACIÓN DE CELDAS EN SISTEMAS UMA.

[0091] A continuación se describe un ejemplo de planteamiento para la identificación de celdas en sistemas UMA. En esta realización, un único UNC ofrece un servicio para una o varias áreas de localización UMA y una o más áreas de enrutamiento UMA, siendo cada área de localización UMA (o cada área de enrutamiento UMA) distinta o igual al área de localización (o de enrutamiento) de la celda GSM superpuesta. Una celda UMA se identifica en el área de ubicación UMA o en el área de enrutamiento mediante la adición de una identidad de celda (CI) a la identificación del área de ubicación o al área de enrutamiento. La identificación global de celda UMA (CGI-UMA) es la concatenación de la identificación del área de ubicación y de la identidad de celda. En una realización, una celda UMA puede ser una partición predefinida del área general de cobertura UMA identificada por un valor UMA-CGI. Téngase en cuenta que la identificación de celda, como la información UMA, puede ser transparente al AP, de modo que el AP no tiene conocimiento de su valor asociado UMA-CGI. Los componentes UMA (por ejemplo el terminal móvil y el UNC) pueden apoyar la capacidad de particionar el total del área de cobertura del sistema UMA.

[0092] Un método de particionar puede incluir la aplicación de correspondencias uno-a-uno o uno-a-varios entre la identidad de la celda GSM y la identidad de la celda UMA. Teniendo en cuenta la identificación de una celda GSM preferida en un área determinada, puede ser posible determinar la identidad correspondiente de la celda UMA basándose, por ejemplo, en recursos del UNC. Un ejemplo de una relación uno-a-uno es el mapeado de una celda GSM a una celda UMA. Un ejemplo de mapeado muchos-a-uno es el mapeado de un área de ubicación GSM (y las celdas GSM) a una celda UMA.

[0093] Cuando una estación móvil UMA se conecta al UNC para proporcionar servicio UMA, se envía el valor CGI y (opcionalmente) un parámetro de criterio de pérdida de ruta (C1) de la celda GSM enrutada actualmente, así como de las celdas vecinas, al UNC. El UNC mapea el valor de la celda CGI en estado de camping respecto al valor CGI de la celda en el UMA correspondiente basándose en la lógica de mapeado disponible en el UNC. Esto puede ser un mapeado uno-a-uno (por ejemplo, si hay una celda UMA por cada celda GSM) o un mapeado muchos-a-uno (por ejemplo, si hay una celda UMA por zona de ubicación GSM). Si no hay cobertura GSM disponible en el área de servicio de la UMA, el UNC puede asignar el terminal móvil a una celda UMA por defecto denominada "cobertura GSM no disponible". Un solo UNC puede proporcionar servicio a un MSC. Esto no excluye realizaciones del UNC que combinan múltiples "instancias" UNC, como ya se mencionó más arriba, en un mismo dispositivo (por ejemplo, un UNC que presta servicio a varios MSCs). A cada UNC también se le puede asignar un único valor "CGIHandover-UMA" que se utiliza con fines de entregas GSM-a-UMA. Por ejemplo, éste puede ser el valor almacenado en las tablas GSM RAN para ARFCN-a-CGI y en el MSC (por ejemplo, para apuntar al UNC).

CONFIGURACIONES OPERATIVAS UMA [0094] En una realización, por lo menos tres configuraciones de funcionamiento UMA pueden identificarse. En una configuración de núcleo de red común, el UMA LAI y un paraguas LAI GSM-RAN (por ejemplo, que presta servicios al barrio del abonado) pueden ser diferentes, y la red puede estar diseñada de tal manera que las mismas entidades de núcleo de red (por ejemplo, MSC y SGSN) den servicio tanto a las celdas UMA y a las celdas paraguas-GSM. Una de las ventajas de esta configuración es que los movimientos del abonado entre el área de cobertura de UMA y el área de cobertura GSM no da lugar a señales entre sistemas (por ejemplo, MAP) (ya que por ejemplo, las actualizaciones de localización y los handovers son intra-MSC).

[0095] En una configuración de núcleo separado, el UMA LAI y el LAI paraguas GSM RAN son diferentes, y la red puede estar diseñada de tal manera que diferentes entidades de núcleo de red den servicio a las celdas de la UMA y a las celdas paraguas GSM. Una de las ventajas de esta configuración es que el diseño de la UMA y de las redes GSM pueden ser más independiente que en la configuración de núcleo común.

[0096] En una configuración de LAI común, el LAI UMA y el LAI GSM RAN son los mismos (por ejemplo, las celdas son diferentes dentro del mismo LAI). Las ventajas de esta configuración son que el movimiento del abonado (mientras está inactiva) entre el área de cobertura UMA y el área de cobertura GSM no da lugar a transmisión de señales de actualización, y que el terminal móvil puede cambiar fácilmente a modo GSM si los recursos en modo UMA están temporalmente fuera de servicio ( por ejemplo, para responder a la paginación). Otros datos de ésta y de la configuración anterior de núcleo separado se discuten en la solicitud de patente nr.10/688,470.

ALTA Y BAJA DE REGISTRO UMA

[0097] En una realización, como se describe anteriormente, un proceso de alta en registro UMA no emplea envío de señales a la infraestructura PLMN y está contenida en el sistema UMA (es decir, entre el terminal móvil y el UNC). El proceso de alta en registro UMA puede servir por lo menos a dos propósitos. Podrá informar al UNC de que una estación móvil está conectado a través de un AP determinado y está disponible en una determinada dirección IP. El UNC puede hacer el seguimiento de esta información, por ejemplo, para transmisiones de terminación de llamada móvil. El proceso de alta en registro también puede proporcionar al terminal móvil con los parámetros de funcionamiento asociados al servicio UMA en el AP. Esto se puede realizar de forma análoga a la utilización del canal de control GSM de difusión (BCCH) para transmitir los parámetros del sistema a los terminales móviles en celdas GSM. El contenido de los mensajes de información de sistema GSM es aplicable en modo UMA puede ser entregado a la estación móvil durante el proceso de registro UMA.

[0098] Del mismo modo, un proceso de baja de registro UMA puede permitir al terminal móvil informar explícitamente al UNC de que está saliendo del modo UMA y permitir así al UNC liberar recursos que pueden estar asignados al terminal móvil. El UNC también puede aportar baja implícita en el registro UMA, donde un canal seguro para el terminal móvil se terminó abruptamente.

REDIRECCIONAMIENTO UMA

[0099] En una realización, como se ha descrito anteriormente, cuando una estación móvil UMA se conecta al UNC para el servicio UMA, puede enviar un valor CGI y un parámetro de criterio de pérdida de ruta (C1) de la celda GSM actualmente enrutada, así como las celdas vecinas, al UNC. Con esta información, así como con información de la base de datos interna, el UNC puede ser capaz de determinar si es el UNC correcto para dar servicio de acceso a la estación móvil, y si no es el UNCC correcto, podrá redireccionar la estación móvil al UNC correcto. El UNC con acceso correcto puede ser el UNC cuya área de servicio UMA se superponga a la cobertura de paraguas GSM de la estación móvil. En una realización, el UNC correcto puede estar conectado al mismo MSC funcionando como BSC GSM al que pertenece la celda GSM paraguas. En una realización alternativa, el UNC correcto puede estar asignado a otro MSC que puede hacer handovers al MSC que ofrece cobertura en el paraguas GSM a la estación móvil, permitiendo al UNC hacer handovers de llamadas desde y hacia al sistema GSM. También puede proporcionar ciertos servicios basados en la localización (por ejemplo, E911-fase 1) que pueden estar vinculado a la ubicación de la celda GSM. Una base de datos interna utilizada por el UNC puede mapear áreas de ubicación GSM para UNCs en servicio y conservar la cantidad de datos que necesita ser gestionada. Esta base de datos sólo se modifica cuando se añade un nuevo UNC o una nueva área de ubicación GSM.

[0100] Si no hay cobertura GSM disponible cuando una estación móvil se conecta al UNC para obtener servicio UMA, a continuación, en algunos casos, el UNC no puede determinar fiablemente la ubicación del terminal móvil a efectos de asignar dicho terminal móvil al UNC con servicio correcto (por ejemplo, para permitir la entrega y los servicios basados en la ubicación). El UNC podrá permitir al operador determinar la política de servicio, en este caso (por ejemplo, el operador puede ofrecer un servicio al usuario con ciertas limitaciones, posiblemente con una indicación de interfaz de usuario en el terminal móvil).

COMPORTAMIENTO EN MODO DE ESPERA UMA DEL TERMINAL MOVIL

[0101] Como se describe anteriormente, un dispositivo UMA puede encontrar diferentes entornos de señal de radio, tal y como se ilustra en la figura 4. En un primer entorno, las áreas de cobertura GSM y UMA están completamente separadas y no superpuestas. En un segundo entorno, la cobertura GSM y UMA se superponen parcialmente. En un tercer entorno, que puede ser el más común, la cobertura UMA está encapsulada dentro de la cobertura GSM. Un dispositivo UMA puede ser el predominante en cualquiera de estos entornos y también pasar a un número de estados como dispositivo secundario.

[0102] Estando encendido y cuando el terminal móvil está en reposo y no hay cobertura de ningún tipo, el terminal móvil puede escanear tanto en busca de cobertura GSM, como de cobertura de radio UMA. Si se detecta cobertura de GSM, entonces el procedimiento de gestión de movilidad GSM normal se puede iniciar. Esta condición puede aplicarse cuando no ha sido detectada cobertura UMA por parte del terminal móvil, cuando se ha detectado cobertura GSM, o antes de la finalización del proceso de registro UMA. Si se detecta cobertura UMA, a continuación el terminal móvil UMA establece un enlace inalámbrico sin licencia (por ejemplo un enlace WLAN) con el AP y vigila la calidad de la señal. Cuando el nivel de señal recibida en el terminal móvil pasa de un límite preestablecido, el terminal móvil lleva a cabo el procedimiento de registro UMA. Basándose en la información devuelta, la estación móvil puede determinar si se requiere un registro completo en la red, y si es así, el tipo del mismo (por ejemplo, registro GSM o combinado GSM/GPRS). Este procedimiento se podrá aplicar cuando no existe cobertura GSM o cuando la cobertura UMA se detecta antes de encontrar cobertura GSM.

[0103] Cuando el terminal móvil está inactivo dentro de cobertura GSM, y no hay cobertura UMA, el terminal móvil puede periódicamente escanear en busca de cobertura UMA. Si se detecta cobertura UMA, el terminal móvil puede iniciar el procedimiento de registro UMA como se ha descrito anteriormente.

[0104] Cuando la estación móvil está inactiva dentro de la cobertura UMA y no hay cobertura GSM, la estación móvil podrá seguir realizando normalmente procedimientos de búsqueda GSM PLMN. Si se detecta cobertura GSM, el terminal móvil puede enviar la información de celda GSM al UNC para posibles fines de redireccioniento UMA como se describe anteriormente. Por otra parte, el terminal móvil puede desactivar los procedimientos de búsqueda normal GSM-PLMN para ahorrar energía.

[0105] Cuando la estación móvil está inactiva dentro de la cobertura UMA, y hay cobertura GSM, la estación móvil podrá seguir desempeñando procedimientos de reselección de celdas GSM normales y puede almacenar la identificación de la celda GSM seleccionada para acelerar la transición a modo GSM, si es necesario. Por otra parte, el terminal móvil puede desactivar los procedimientos normales de reselección de celda GSM para ahorrar energía.

[0106] Cuando está apagada dentro de cobertura UMA, una indicación de separación pueden ser enviada por el terminal móvil a la PLMN a través de UMAN (por ejemplo, si es requerido por la red PLMN enviados por el terminal móvil apagado de forma normal). Esta indicación puede ser codificada por el modo de operación GSM actual (por ejemplo, GSM o GPRS).

[0107] El entorno UMA puede ser un entorno de IEEE 802.11. En este caso, el terminal móvil realiza periódicamente una lectura activa de puntos de acceso 802.11 disponibles. Cuando se descubre un punto de acceso, éste puede ser comparado con un perfil almacenado de las preferencias de usuario y con credenciales de seguridad, en cuyo caso la estación móvil puede asociarse de forma automática con el AP. El terminal móvil puede entrar en modo de bajo consumo y activarse periódicamente para medir la calidad de la señal y determinar así cuándo activar el registro UMA.

[0108] El entorno de la UMA puede ser un entorno Bluetooth. En este caso, el terminal móvil vinculado previamente al AP Bluetooth tendrá acceso a servicio UMA mediante Bluetooth. Periódicamente, el terminal móvil puede entrar en un modo de recepción de exploración de página y responder a un AP con una transmisión de página para establecer una conexión de nivel de enlace. Una vez que un canal de control de nivel de enlace se establece, y si el terminal móvil está activo con otro proceso, éste puede entrar en un estado Bluetooth de bajo consumo (por ejemplo, modo aparcado) para ahorrar energía. Periódicamente, el AP puede sondear el terminal móvil para que le permita volver a entrar en el modo de energía activa. Este tráfico periódico también puede ser utilizado por el terminal móvil para medir la calidad de la señal y determinar cuándo realizar el procedimiento de registro UMA.

TRANSICIONES SIN FISURAS DE SERVICIOS DE DATOS

[0109] Un dispositivo UMA que participa en una transacción de datos o de voz y de datos simultáneamente puede encontrar una transición de cobertura GSM a cobertura UMA o una transición de cobertura UMA a cobertura GSM. En una realización, cuando las transiciones de cobertura GSM a cobertura UMA, las sesiones de llamadas y datos pueden ser entregadas de forma transparente entre el RAN GSM y la UMAN. En el caso de la voz, la entrega se puede lograr mediante una función de entrega (handover). En el caso de los datos, los procedimientos de gestión de movilidad GPRS permiten transiciones sin fisuras de las sesiones de paquetes de datos activos. Las acciones normales de registro se pueden producir durante el retorno al estado de reposo, si resultara apropiado. Durante las transiciones de cobertura UMA a cobertura GSM, las llamadas pueden ser entregadas de forma transparente entre la UMAN y la RAN GSM. En el caso de la voz, la entrega se puede lograr mediante una función de entrega (handover). En el caso de los datos, los procedimientos de gestión de movilidad GPRS permiten transiciones sin fisuras de las sesiones de paquetes de datos activas.

MENSAJES PARA LA GESTIÓN DE CONTROL DE ENLACE DE RADIO SIN LICENCIA (URLC)

[0110] El canal de transporte URLC (URLC TC) está definido como conexión URLC punto a punto de tipo UDP entre la MS y el UNC utilizado para la transferencia de datos GPRS del usuario. El canal de transporte URLC proporciona información entre la MS y el UNC para el transporte de datos de usuario GPRS mediante la interfaz ascendente. Dado que el transporte de datos del usuario UMAN está basado en el UDP, el canal de transporte URLC está asociado con las direcciones IP de la MS y del UNC correspondientes y con los puertos UDP utilizados para la transferencia de datos de usuario. La MS y el UNC gestionan el canal de transporte URLC en base a las solicitudes de transferencia de datos y a un temporizador configurable URLC-CHANNEL-TIMER.

[0111] A continuación se muestra el resumen de las características URLC TC y de los procedimientos asociados:

1.: URLC TC define el destino de enlace ascendente de la dirección IP del UNC y del puerto UDP UNC a ser usados por la MS para la transferencia de datos de usuario GPRS. Además la MS mantiene el valor del temporizador URLC-CHANNEL-TIMER que es recibido como uno de los parámetros de sistema en el mensaje URR REGISTER ACK.

2.: El URLC TC define el destino de enlace descendente de la dirección IP de la MS y del puerto UDP MS a ser usados por el UNC para la transferencia de datos de usuario GPRS.

3.: La MS o el UNC activarán el URLC TC sólo cuando la transferencia de datos GPRS esté iniciada y el URLC se encuentre en estado URLC-STANDBY. Los datos de usuario GPRS de enlace ascendente y descendente pueden ser transferidos inmediatamente cuando el URLC TC ya existe, es decir, el URLC está en estado URLC-ACTIVE.

4.: No hay necesidad de un mecanismo de mantenimiento de canal de transporte específico URLC ya que el tunel IPSec se usa para todo el tráfico de datos GPRS y se encargará de los procedimientos de mantenimiento de nivel IP.

5.: No hay necesidad de una solución separada NAT transversal para el transporte de datos URLC ya que el tunel IPSec se usa para el tráfico de datos GPRS y se encargará de los procedimientos de NAT transversal.

[0112] La figura 5 muestra los estados URLC y el comportamiento asociado por parte de la MS. A continuación se muestra la definición de los estados URLC de la MS:

URLC-SERVICE-DETACHED: El URLC y todas las capas inferiores de protocolo ascendente están inicializadas y operativas, sin embargo el URLC no está conectado a los puntos de acceso de LLC GRR y GMMRR (SAPs) y el GSM/GPRS RR/RLC controla los GPRS SAPs, es decir, todas las solicitudes de las capas superiores se dirigen al GSM/GPRS RR/RLC y el URLC no puede comunicarse con las capas superiores (LLC y GMM). El MS está en modo GSM.

URLC-SERVICE-ATTACHED: El URLC está conectado a los puntos de acceso de LLC GRR y GMMRR (SAPs) y el GSM/GPRS RR/RLC no está conectado a los GPRS SAPs, es decir, todas las solicitudes de las capas superiores se dirigen al MS URLC y el GSM/GPRS RR/RLC no puede comunicarse con las capas superiores (LLC y GMM). El MS está en modo UMA.

URLC-STANDBY: Este es el subestado inicial / estándar del estado URLC-SERVICE-ATTACHED. El MS no es capaz de recibir o enviar datos de usuario GPRS de o al UNC. El canal de transporte URLC no existe cuando el MS está en estado URLC-STANDBY. EL UNC o el MS necesitan activar el canal de transporte URLC antes de enviar datos de usuario GPRS. Cuando el URLC del MS activa con éxito el canal de transporte URLC, hace una transición al estado URLC-ACTIVE.

URLC-ACTIVE: Este es el subestado del estado URLC-SERVICE-ATTACHED. El MS es capaz de recibir o enviar datos de usuario GPRS de o al UNC. El canal de transporte correspondiente URLC existe.

[0113] Inicialmente e inmediatamente después de encender el dispositivo, el MS está en modo GSM y URLC está en estado URLC-SERVICE-DETACHED. Cuando se detecta cobertura UMAN, la selección de modo da preferencia a UMAN y, tras un registro UMA con éxito, el MS conmuta a modo UMA. Simultáneamente, el URLC del MS toma el control del LLC GRR y de los SAPs GMMRR y hace una transición al estado URLC-SERVICE-ATTACHED. El GSM/GPRS RR/RLC está desconectado ahora y no controla los SAPs GPRS.

[0114] Al entrar en estado URLC-SERVICE-ATTACHED, el URLC del MS inicialmente hace una transición al estado URLC-STANDBY y el URLC TC correspondiente deja ahora de existir. El URLC del MS debe ser capaz de almacenar en búfer el o los paquetes de datos de enlace ascendente mientras la activación del TC URLC se está realizando. Tras una activación con éxito del URLC TC, el URLC del MS hace una transición al estado URLC-ACTIVE. Los siguientes son los disparadores potenciales para la activación del URLC TC por parte del MS:

1.: El LLC inicia la transferencia de datos de enlace ascendente usando LLC SAPI 3, 5, 9, u 11.

2.: El UNC inicia la activación URLC TC, es decir, el MS recibe un mensaje URLC-ACTIVATE-GPRS-TC-REQ del UNC.

[0115] Mientras el URLC está en estado URLC-ACTIVE, el URLC TC correspondiente existe y el transporte de datos de usuario GPRS está activa tanto en dirección ascendente como descendente. Durante la activación con éxito del URLC TC y paralelamente a la transición al estado URLC-ACTIVE, el URLC del MS inicia el temporizador URLC-CHANNEL-TIMER. El temporizador es reiniciado siempre que se envía cualquier paquete de datos de usuario de enlace ascendente o se recibe un paquete de datos de usuario de enlace descendente. Cuando caduca el URLC-CHANNEL-TIMER, el MS envía un mensaje URLC-DEACTIVATE-GPRS-TC-REQ al UNC para iniciar la desactivación del URLC TC. Tras una desactivación con éxito del URLC TC, el URLC del MS hace una transición al estado URLC-STANDBY.

[0116] En cualquier momento estando en estado URLC-SERVICE-ATTACHED, si la MS pasa a modo GSM o el radioenlace UMAN se pierde, dando lugar a cancelación de registro en UMAN, el URLC se desconecta de los GPRS SAPs y el URLC de la MS entra en estado URLC-SERVICE-DETACHED. Simultáneamente, el MS liberará el URLC TC asociado independientemente del estado del URLC-CHANNEL-TIMER.

[0117] El URLC del MS mantiene un URLC TC para todos los flujos activos de datos de usuario, es decir, si el URLC está en estado URLC-ACTIVE, cualquier paquete de datos de usuario de enlace ascendente se transfiere usando el URLC TC activo independientemente de los PFCs y LLC SAPs asociados. De forma análoga, el URLC-CHANNEL-TIMER es reiniciado siempre que se envía cualquier paquete de datos de usuario de enlace ascendente

o se recibe un paquete de datos de usuario de enlace descendente independientemente de los PFCs y LLC SAPs asociados.

[0118] Los estados del URLC por parte de la red están basados en el MS, es decir, el contexto de información de estado URLC se mantiene por el MS activo. El UNC mantiene los canales de transporte URLC y los estados URLC correspondientes para todas las estaciones móviles que participan activamente en la transferencia de datos de usuario GPRS. El URLC TC está asociado con el MS y es activado sólo cuando tiene lugar el transporte real de datos de usuario. El número máximo de canales de transporte asignados simultáneamente por MS es uno.

[0119] La figura 6 muestra los estados URLC por parte de la red. Los siguientes estados están definidos:

URLC-STANDBY: El canal de transporte URLC no existe cuando el URLC está en estado URLC-STANDBY. Cuando el canal de transporte URLC correspondiente está activado, el URLC pasa a estado URLC-ACTIVE.

URLC-ACTIVE: El canal de transporte correspondiente URLC existe.

[0120] Inicialmente, después de que el MS se registre para el servicio UMA, el estado URLC correspondiente es URLC-STANDBY. Tras la activación con éxito del URLC TC asociado, el URLC entra en estado URLC-ACTIVE. Tanto el MS como el UNC pueden iniciar la activación del URLC TC. Si la activación fue iniciada por la MS, el UNC actualiza el estado URLC después de haber localizado con éxito el URLC TC y reenviando el mensaje de confirmación a la MS. Si la activación fue iniciada por el UNC, el UNC actualiza el estado URLC después de recibir el mensaje de confirmación de la MS. El UNC debe ser capaz de almacenar en búfer los paquetes de datos de enlace descendente para la MS mientras la activación URLC TC está en progreso. Mientras el URLC está en estado URLC-ACTIVE, el UNC mantiene la información requerida asociada con el URLC TC y con el estado URLC. Esto permite al UNC enviar y recibir automáticamente datos de usuario GPRS del y al MS mientras el URLC está activo, es decir, mientras el URLC TC correspondiente existe.

[0121] Tras la desactivación del URLC TC, el URLC entra en el estado URLC-STANDBY. Si la desactivación la inició el MS, el UNC actualiza el estado del URLC después de que se libere el URLC TC asociado y se envía el mensaje de conformación al MS. Si la desactivación se dispara debido a la cancelación de registro en UMA, el UNC actualiza inmediatamente el estado URLC y ha liberado el URLC TC asociado.

[0122] Se usa el protocolo TCP para apoyar la señalización de canales entre el MS y el UNC a través de los que los mensajes de protocolo UMA RR y UMA RLC se transfieren en ambas direcciones. Cada MS establece una única conexión TCP con el UNC para señalizar mensajes de servicios GSM y GPRS. Mientras tanto, UDP se usa para dos objetivos: Para apoyar la transferencia bidireccional del tráfico del plano de usuario GPRS entre el UNC y el MS y 2) para apoyar la transferencia de paquetes de voz RTP/RTCP entre el UNC y el MS. FORMATOS DE MENSAJE URLC

[0123] El protocolo de modo de confirmación UMA-RLC proporciona una entrega de mensaje fiable a través de la interfaz ascendente, usando la misma conexión TCP que UMA RR. Los mensajes de señalización UMA-RLC, los de señalización GPRS y los de SMS son transferidos usando este servicio. Cada mensaje UMA-RLC incluye los siguientes elementos informativos (IEs):

1.: Diferenciador de protocolo UMA-RLC. Para distinguir los mensajes UMA-RLC de los mensajes UMA-RR, el protocolo UMA-RLC usa el diferenciador de protocolo 0111 para los bits del 3 al 0 del primer octeto de cada mensaje UMA-RLC. Los bits restantes se establecen como 0. Cabe señalar que esto no es más que un ejemplo y que como secuencias se podrán utilizar otras, dependiendo de la aplicación en particular.

2.: Indicador de salto / de sustitución - En una realización, los bits 5-8 del primer octeto de cada mensaje UMA-RLC contienen el indicador sustitución o el de salto. (Desde un punto de vista binario, los IEs de indicador de salto y de sustitución son idénticos y realizan la misma función). Un mensaje UMA-RLC recibido con un indicador de salto / de sustitución diferente de 0000 no se tendrá en cuenta.

3.: Tipo de mensaje - El IE (elemento de información) de tipo de mensaje y su uso se definen en GSM04.07. Los tipos de mensaje UMA-RLC para una realización se enumeran en el cuadro 1 más abajo.

4.: Otros elementos de información, en función de las necesidades.

i. La columna de presencia indica si un elemento de información es obligatorio ("M"), opcional ("O") o si aparece condicionado por otro(s) factor(es) ("C").

ii. La columna del formato indica como esta formateado el IE: "TLV" para formato etiquetas-longitudvalor (TLV por sus siglas inglesas); "LV" para longitud-valor y "V" para valor. La etiqueta del IE también se conoce como identificador del elemento de información (IEI). Los elementos de información de uso obligatorio usan formato "V" o "LV", dependiendo de si son de longitud fija o variable. Los elementos informativos opcionales y condicionados siempre usan formato "TLV".

5.: Indicador de longitud. En una realización, un indicador de longitud IE independiente se utiliza para especificar la longitud de un mensaje determinado. En otra realización, la capa de transporte subyacente se utiliza para proporcionar una indicación de longitud de cada mensaje. Como corresponde, un indicador independiente de longitud IE no está incluido en este formato. Ambos tipos de formatos son ilustrados por los mensajes URLC divulgados en el presente documento.

TABLA 1

ACTIVACIÓN DEL CANAL DE TRANSPORTE URLC (URLC TC) INICIADA POR EL MS.`

[0124] Una activación del URLC TC iniciada por el MS es activada por la petición de transferencia de datos GPRS cuando el URLC se encuentre en estado URLC-STANDBY. Un ejemplo de una secuencia de intercambio de mensajes de activación URLC TC iniciada por el MS se muestra en la figura 7A. Los mensajes y las señales asociadas que pasan entre los diferentes elementos en las figuras se muestran como flechas horizontales o puntas de flecha conectando los elementos del sistema de comunicaciones implicados. Cuando la flecha pasa a través de un elemento y no se muestra la punta de flecha, entonces este elemento funciona como simple paso. Los aspectos particulares del sistema de comunicación que se muestran en la figura 7A se muestran en el diagrama son, de izquierda a derecha, una estación móvil (por ejemplo 102), un punto de acceso (por ejemplo el WLAN AP 128), un UNC (por ejemplo el UNC 140).

[0125] Antes de las operaciones ilustradas, varias operaciones se realizan para establecer una conexión entre el MS 102 y el AP 128, para luego establecer una conexión entre el MS 102 y el UNC 140. En el paso A, una conexión TCP se ha establecido entre el MS 102 y el UNC 140. Tras recibir la petición de transferencia de enlace ascendente de datos de usuario del LLC para los SAPs LLC 3, 5, 9 u 11 (no se muestran) y mientras el URLC MS está en el estado URLC-STANDBY, el URLC MS prepara un mensaje URLC-ACTIVATE-UTC-REQ 700 e incluye los siguientes elementos informativos: Dirección IP del MS para la transferencia de enlace descendente de datos de usuario GPRS y el número de puerto UDP del MS para la transferencia de enlace descendente de datos de usuario GPRS (véase la figura 8 y la argumentación más abajo). Como consecuencia, el URLC del MS envía el mensaje URLC-ACTIVATE-UTC-REQ al UNC en el paso B e inicia el temporizador URLC-TCA-TIMER para esperar la respuesta. El URLC del MS almacena en búfer los paquetes de datos de enlace ascendente mientras la activación del TC URLC se está realizando.

[0126] Tras recibir el mensaje URLC-ACTIVATE-UTC-REQ del MS, el UNC verifica que: El MS está registrado en la UMA; el URLC están en estado URLC-STANDBY y el TC URLC asociado con el MS no existe. Si todos los controles tienen éxito, el UNC asigna la dirección IP y el número de puerto UDP para el transporte de datos de usuario GPRS en el MS. Si la asignación tiene éxito, el UNC crea el URLC TC correspondiente y almacena la información asociada. El estado URLC se actualiza a URLC-ACTIVE. En consecuencia, el UNC envía un mensaje URLC-ACTIVATE-UTC-ACK 702 al MS con la causa de la activación, como se muestra en el paso C de la figura 7A. El mensaje incluye la dirección IP del UNC y del puerto UDP UNC a ser usados por el MS para la transferencia de datos de usuario GPRS.

[0127] Tras recibir el mensaje URLC-ACTIVATE-UTC-ACK mientras la activación del URLC TC del MS está en progreso, el MS detiene el temporizador URLC-TCA-TIMER, crea y almacena el registro correspondiente URLC-TC con la información requerida y el URLC TC pasa a estado URLC-ACTIVE. El URLC en el MS inicia el URLC-CHANNEL- TIMER y reenvía todos los paquetes de datos de usuario de enlace ascendente que queden. El temporizador es reiniciado siempre que se envía cualquier paquete de datos de usuario al UNC o se recibe de este.

[0128] Los detalles de una realización del mensaje URLC-ACTIVATE-UTC-REQ se muestran en la figura 8. A efectos ilustrativos, cada formato de mensaje que se muestra en este documento incluye una columna de elemento de información; una columna tipo / referencia; una columna de presencia; una columna de formato; una columna de longitud y una columna de valor o de valor/indicaciones. Cabe señalar que los mensajes reales incluyen un valor que identifica el tipo de mensaje, junto con los valores correspondientes IE de acuerdo con cada formato de mensaje particular. Por tanto como con cada uno de los mensajes mostrados aquí, el mensaje URLC-ACTIVATE-UTC-REQ 700 incluye un IE de diferenciador de protocolo UMA RLC, un IE de indicador de salto, un IE de tipo de mensaje (URLC- ACTIVATE-UTC-REQ en esta instancia). Como se utiliza aquí, estas cuatro entidades independientes son denominadas como IE "básicos" para indicar que se incluyen en cada formato de mensajes.

[0129] En una realización, el TLLI (identidad de enlace lógico temporal) IE contiene el campo de valor definido en 3GPP TS44.018. La dirección IP para el IE de transporte de datos de usuario GPRS contiene la dirección IP del MS de transporte de datos de usuario GPRS si el MS inicia la activación. Contiene la dirección IP del UNC para el transporte de datos de usuario GPRS si el UNC inicia la activación (como se muestra en la figura 10). El puerto UDP para el IE de transporte de datos de usuario GPRS contiene el puerto UDP del MS para el transporte de datos de usuario GPRS si el MS inicia la activación. Contiene el puerto UDP del UNC para el transporte de datos de usuario GPRS si el UNC inicia la activación.

[0130] La figura 9 muestra detalles de una realización de un mensaje URLC-ACTIVATE-UTC-ACK 702. Además de los IEs básicos, este formato de mensaje incluye una dirección IP para el IE de transporte de datos de usuario GPRS, un puerto UDP para el IE de transporte de datos de usuario GPRS; una dirección IP remota para el IE de transporte de datos de usuario GPRS; un puerto remoto UDP para el IE de transporte de datos de usuario GPRS y un IE de estado de activación URLC TC. La dirección IP para el IE de transporte de datos de usuario GPRS debe estar incluida si la causa URLC indica éxito (0 ó 1) y contiene una dirección IP de la MS para el transporte de datos de usuario GPRS si la MS indica activación o una dirección IP del UNC para el transporte de datos de usuario si un UNC inicia la activación. El puerto UDP para el IE de transporte de datos de usuario GPRS debe estar incluido si la causa URLC indica éxito (0 ó 1) y contiene un puerto UDP del MS para el transporte de datos de usuario GPRS si el MS indica activación o un puerto UDP para el transporte de datos de usuario si un UNC inicia la activación.

[0131] La dirección IP remota para el IE de transporte de datos de usuario GPRS debe estar incluida si se responde a una petición duplicada de activación URLC cause= 1. Contiene una dirección IP del MS para el transporte de datos de usuario GPRS si el UNC indica activación o una dirección IP del UNC para el transporte de datos de usuario si un MS inicia la activación. El puerto UDP remoto para el IE de transporte de datos de usuario GPRS debe estar incluido si se responde a una petición de activación duplicada URLC-Causa = 1. Contiene un UDP del MS para el transporte de datos de usuario GPRS si un UNC indica activación o un puerto UNC UDP para el transporte de datos de usuario GPRS si un MS inicia la activación. El IE de estado de activación URLC TC contiene un valor codificado identificando el estado de activación y/o de causa del fallo. Un conjunto ejemplificado de valores de causa URLC se muestra en la figura 10.

ACTIVACIÓN URLC TC INICIADA POR LA RED.

[0132] Una activación del URLC TC iniciada por el UNC es activada por la petición de transferencia de datos descendente GPRS cuando el URLC se encuentre en estado URLC-STANDBY. Las figura 7B muestra un flujo de mensajes ilustrando los mensajes y temporizadores asociados a este procedimiento. Como anteriormente, una conexión TCP se ha establecido entre la MS 102 y el UNC 140 en el paso A. Tras recibir la petición de transferencia de enlace descendente de datos de usuario del LLC para los SAPs LLC 3, 5, 9 u 11 (no se muestran) y mientras el URLC está en estado URLC-STANDBY, el UNC localiza la dirección IP y el número de puerto UDP para el transporte de datos de usuario GPRS en la MS. Partiendo de una localización con éxito, el UNC prepara un mensaje URLC-ACTIVATE-UTC-REQ 700 que incluye una dirección IP UNC para la transferencia del enlace ascendente de datos de usuario GPRS y un número de puerto UNC UDP para la transferencia del enlace ascendente de datos de usuario GPRS. Como consecuencia, en el paso B, el URLC envía el mensaje URLC-ACTIVATE-UTC-REQ 700 al MS e inicia el temporizador URLC-TCA-TIMER para esperar la respuesta.

[0133] Tras recibir el mensaje URLC-ACTIVATE-UTC-REQ del UNC, el MS verifica que: el URLC esté en estado URLC-STANDBY; el URLC TC correspondiente no existe y el servicio GPRS no está suspendido. Si la verificación tiene éxito, el MS asigna la dirección IP y el número de puerto UDP para el transporte de datos de usuario GPRS en el MS y almacena la información asociada. El estado URLC se actualiza a URLC-ACTIVE y el URLC del MS inicia el URLC-CHANNEL-TIMER. En consecuencia, en el paso C, el UNC envía un mensaje URLC-ACTIVATE-UTC-ACK 702 al UNC con la causa de la activación con éxito. El mensaje incluye la dirección IP del MS y del puerto UDP del MS a ser usados para el transporte de enlace descendente de datos de usuario GPRS.

[0134] Tras recibir el mensaje URLC-ACTIVATE-UTC-ACK 702 mientras la activación por parte del UNC del URLC TC está en progreso, el UNC detiene el temporizador URLC-TCA-TIMER, crea y almacena el registro correspondiente URLC-TC con la información requerida y el URLC pasa a estado URLC-ACTIVE. El UNC entonces reenvía cualquier paquete de datos de usuario de enlace descendente que quede.

DESACTIVACIÓN DEL CANAL DE TRANSPORTE URLC INICIADA POR EL MS

[0135] Cuando el URLC-CHANNEL-TIMER caduca, el URLC del MS inicia la desactivación del URLC TC enviando la petición al UNC como en el flujo de mensajes ilustrado en la figura 11. Más concretamente, cuando el URLC-CHANNEL- TIMER caduca (paso A) y si no hay más mensajes de datos de usuario de enlace ascendente GPRS por transferir, el MS envía un mensaje URLC-DEACTIVATE-UTC-REQ 1100 al UNC para solicitar la desactivación e inicia su URLC-TCA-TIMER para esperar la confirmación.

[0136] Tras recibir el mensaje URLC-DEACTIVATE-UTC-REQ del MS, el UNC verifica que: El MS está registrado para dar servicio UMA, el URLC TC correspondiente está en estado URLC Active y el URLC TC correspondiente existe. Presuponiendo una verificación exitosa, el UNC envía un mensaje URLC-DEACTIVATE-UTC-ACK 1102 al MS indicando la causa de la desactivación, con el IE fijado en “éxito”. El UNC libera el URLC TC correspondiente y actualiza el estado URLC a URLC-STANDBY. Tras recibir el mensaje URLC-DEACTIVATE-UTC-ACK 1102 del UNC, el URLC del MS detiene su URLC-TCA-TIMER y libera el URLC TC. Paralelamente el URLC del MS hace una transición al estado URLC-STANDBY.

[0137] Los detalles de una realización del mensaje URLC-DEACTIVATE-UTC-REQ 1100 se muestran en la figura

12. Además de los IEs básicos, este formato de mensaje incluye un IE TLLI y un IE de causa de desactivación URLC TC. El valor de este IE identifica la causa de la desactivación (mediante la consulta de la tabla de valores de causa URLC de la figura 10). Los detalles de una realización del mensaje URLC-DEACTIVATE-UTC-ACK 1102 se muestran en la figura 13. Además de los IEs básicos, este formato de mensaje incluye un IE TLLI.

DESACTIVACIÓN IMPLÍCITA DEL CANAL DE TRANSPORTE URLC

[0138] Si se realiza el proceso de baja en el registro UMA en una estación móvil con un TC URLC activo, el UNC libera automáticamente el TC URLC asociado y borra los registros relaciones incluyendo la información de estado URLC. El MS libera el TC URLC y el MS URLC entra en estado URLC-SERVICE-DETACHED tras la cancelación del registro en UMA. Esto incluye escenarios en los que la cancelación de registro UMA se realiza por fallos de la capa inferior, es decir, pérdida de radio conexión, de conexión segura, etc.

SEÑALIZACIÓN URLC GPRS Y TRANSPORTE DE MENSAJES SMS [0139] Mientras la MS está registrada para servicios UMA, la sesión correspondiente TCP para el transporte de señal está disponible siempre y, asumiendo que los URR MS y el URLC están asociados a los SAPs GSM/GPRS, tanto la estación móvil como el UNC pueden iniciar la señalización GPRS o la transferencia de mensajes automática usando el servicio URLC DATA como se ilustra en la figura 14. El mecanismo de transporte URLC-DATA se utiliza para toda la señalización GPRS/GMM/SM y para los mensajes SMS. La señalización GPRS y los mensajes SMS usan como túnel el transporte por TCP entre el MS y el UNC. La gestión de sesión TCP (establecimiento y liberación) son responsabilidad de la capa de transporte y la misma sesión TCP se usa para señalización GSM, GPRS y UMA.

[0140] La secuencia de flujo de mensajes en la figura 14 puede iniciarse en cualquier momento mientras la sesión TCP en el paso A está activa. En el paso B, el MS 102 envía un mensaje URLC-DATA 1400 al UNC 140 para iniciar la transferencia de mensajes SMS / señalización GPRS de enlace ascendente. En el paso C, el UNC se ilustra enviando un mensaje URLC-DATA 1400 al MS para iniciar la transferencia de mensajes SMS / señalización GPRS de enlace ascendente.

[0141] El MS inicia la transferencia de mensajes SMS / señalización GPRS de enlace ascendente de la siguiente manera. Asumiendo que la sesión de señalización TCP siempre está disponible mientras el MS está registrada en la UMAN, el URLC en el MS es capaz de retransmitir cualquier señal de enlace ascendente GPRS o cualquier mensaje SMS al UNC. Después de la petición del LLC de transferir un enlace ascendente LLC PDU portando un mensaje de señal GPRS (identificado con LLC SAP 1) o un mensaje SMS GPRS (LLC SAP 7), el URLC de la MS encapsula el LLC PDU completo con un mensaje URLC-DATA 1400, de lo que muestra una realización la figura 15. En consecuencia, el MS retransmite el mensaje URLC-DATA al UNC usando la sesión TCP existente de señalización.

[0142] Además de los IEs básicos, el formato de mensaje incluye un IE de calidad de servicio requerida (Required QoS) un ID de prioridad de radio requerida, un IE de PFI y el LLC PDU encapsulado. El IE de calidad de servicio requerida define el total máximo requerido o solicitado. La información puede especificarse mediante un código de 4 bits o puede proporcionarse por el LLC en la petición LLC PDU. La prioridad de radio requerida se incluye como un componente del IE de calidad de servicio conforme al estándar 3GPP TS 48.018. El IE de PFI (indicador de flujo de paquetes) está incluido si el componente de flujo de paquete es soportado por el MS y por la red núcleo.

[0143] En una realización, el formato de mensajes incluye además un primer IE de indicación de paquete. Este IE se usa para identificar si un paquete es el primer paquete en un enlace ascendente y se establece como 1 cuando el primer paquete de enlace ascendente se envía a través de la red UMA después de que el MS esté encendida o activa. El valor del primer IE de indicación de primer paquete se establece a 0 para los siguientes paquetes de enlace ascendente. Este IE es ignorado o no se incluye en dirección descendente.

[0144] Tras recibir la señal GPRS de enlace ascendente o el mensaje SMS de la MS, el UNC extrae el LLC PDU recibido y los parámetros de mensaje disponibles, determina el SGSN, el BVCI en servicio y la identidad de celda UMAN, incluyendo el RAI y construye el correspondiente PDU BSSGP-UL-UNIT-DATA. En consecuencia el UNC enlaza el PDU al SGSN mediante la interfaz Gb usando el procedimiento de enlace ascendente UNIT DATA en el BSSGP como en el estándar GPRS.

[0145] Un UNC inicia la transferencia de mensajes SMS / señalización GPRS de enlace descendente de la siguiente manera. Tras recibir un PDU BSSGP-DL-UNITDATA para la MS que contiene un PDU LLC de enlace descendente con señalización GPRS o un mensaje SMS identificado con LLC SAP 1 ó 7 respectivamente, el UNC encapsula el LLC PDU por completo dentro de un mensaje URLC-DATA e incluye los siguientes parámetros. Un IE TLLI se incluye como componente del encabezamiento URLC UNITDATA. El PFI está incluido si el componente de flujo de paquete es soportado por el MS y por la red núcleo. En consecuencia, el MS retransmite el mensaje URLC-DATA al MS usando la sesión TCP existente de señalización. Tras recibir el mensaje URLC-DATA que incluye la señal de enlace descendente GPRS o el PDU SMS LLC del UNC, la MS extrae el PDU LLC recibido y el TLLI y lo reenvía al PDU a la capa LLC a través del SAP GRR conforme al estándar GPRS.

PARA PAGINACIÓN URLC EL SERVICIO DE PAQUETES CONMUTADOS (PS)

[0146] El SGSN inicia el procedimiento de paginación del servicio de paquetes conmutados GPRS antes de iniciar la transferencia de datos descendente a la estación móvil en estado GMM-STANDBY. En la implementación estándar GPRS, el SGSN envía una petición de paginación al BSS indicando el área donde se debe realizar la paginación. El BSS entonces página el MS en el grupo de celdas indicado utilizando la interfaz de radio GSM/GPRS. La paginación en modo UMAN es más eficiente que en GPRS ya que el UNC mantiene la localización exacta de todas los MS registradas en la red UMAN y, en consecuencia, la petición de paginación se enruta directamente al MS específico y se realiza sólo si el MS está registrada en UMAN.

[0147] La figura 16 ilustra las interacciones que tienen lugar en el procedimiento de paginación PS a través de la red UMAN. Tras recibir un PDU PS de paginación ( en un mensaje de paginación GMM-PS) a través de la interfaz BSSGP del SGSN en el paso A, el UNC verifica que el MS correspondiente esté registrada en UMAN y que el MS pueda usar servicios GPRS mediante la red UMAN. Asumiendo que el UNC determina que el MS está en este momento registrada para servicios GPRS, el UNC construye el mensaje correspondiente URLC-PS-PAGE 1600 que incluirá el IE de identidad móvil recibido en la petición original, por ejemplo, el PTMSI o IMSI u otro identificador aplicable. Un formato ejemplificado para el mensaje URLC-PS-PAGE 1600 se muestra en la figura 17. En consecuencia, el UNC reenvía el mensaje URLC-PS-PAGE 1600 al MS a través de la sesión de señales TCP, como se muestra en el paso B.

[0148] Tras recibir un mensaje URLC-PS-PAGE del UNC, el URLC en el MS reenvía la indicación a la capa GMM usando el SAP GMMRR conforme al estándar GPRS. En consecuencia, el MS envía un PDU LLC de enlace ascendente como respuesta de paginación conforme al estándar GPRS. El MS podrá enviar o un mensaje URLC-DATA 1400 o un mensaje URLC-UNITDATA 2600 (descrito abajo. Dado que el MS responde a paginación PS con cualquier PDU LLC encapsulado conforme al mensaje estándar URLC-DATA o URLC-UNITDATA (pasos C y D), el UNC procesará el mensaje como cualquier otra señal GPRS/SMS o mensaje de datos de usuario.

PROCEDIMIENTO DE SUSPENSIÓN GPRS

[0149] El servicio de suspensión GPRS proporciona un mecanismo al MS para notificar al SGSN cuando el servicio GPRS de enlace ascendente necesita ser suspendido. Las interacciones de procedimiento de suspensión GPRS se muestran en la figura 18. El MS suspenderá el servicio GPRS dentro de cobertura UMAN mientras hace la transición a modo dedicado si no es capaz de soportar servicios de circuito conmutado y de paquetes de datos simultáneamente. La red UMA soporta servicios simultáneos de circuito conmutado y de paquetes de datos.

[0150] Mientras hace la transición al modo dedicado y si es incapaz de soportar servicios de circuito conmutado y de paquetes simultáneamente, el MS solicita la suspensión de la transferencia de datos GPRS de enlace descendente enviando un mensaje URLC-SUSPEND-REQ 1800 al UNC, como se muestra en el paso A en la figura

18. Como se muestra en un formato de mensaje para el mensaje URLC-SUSPEND-REQ 1800 en la figura 19, el mensaje incluye el TLLI y los IEs de causa conformes al estándar GSM/GPRS. El mensaje se transfiere a través de la señalización de la sesión TCP. Tras recibir el mensaje URLC-SUSPEND-REQ del MS, el UNC extrae el TLLI recibido como parámetro y construye el mensaje de petición de suspensión BSSGP GMM conforme al estándar GPRS. En consecuencia, el UNC inicia y completa el procedimiento de suspensión GPRS a través de la interfaz Gb conforme al estándar GPRS, como se muestra en el paso B.

PROCEDIMIENTO DE REANUDACIÓN GPRS

[0151] El procedimiento de reanudación GPRS habilita un mecanismo de reanudación del servicio GPRS de enlace de bajad, si fue suspendido previamente, después de que el procedimiento de modo dedicado está completado. Las interacciones de procedimiento de reanudación GPRS se muestran en la figura 20. Tras recibir un comando de aprobación 2000 de la red núcleo (en el paso A) indicando que el procedimiento de modo dedicado está completado y que el canal RR necesita ser activado y si el servicio GPRS ha sido suspendido para ese MS, el UNC inicia el procedimiento de reanudación GPRS a través de la interfaz Gb (paso B). Tras haber sido completado, el UNC reenvía un mensaje URR-RELEASE 2002 al MS incluyendo la indicación de reanudación del estándar GPRS. Una realización de un mensaje URR RELEASE 2002 incluyendo un IE de reanudación de GPRS se muestra en la figura 21.

[0152] Tras recibir un mensaje URR-RELEASE 2002 del UNC, y si el servicio GPRS ha sido suspendido, la capa URR en el MS reenvía la indicación a la capa MM/GMM conforme al estándar GSM/GPRS. Dependiendo de la indicación, la capa GMM puede iniciar el procedimiento de reanudación GPRS conforme al estándar GSM/GPRS.

CONTROL DE FLUJO DE ENLACE DESCENDENTE INICIADO POR EL MS

[0153] El control de flujo de enlace descendente iniciado por el MS se basa en el mecanismo de control de flujo de enlace descendente estándar GPRS mejorado para el servicio UMA. El MS implementa el algoritmo de control de flujo para vigilar y calcular la tasa de datos que puede soportarse en base a las condiciones actuales. Cuando se detecta la condición de control de flujo (por ejemplo cuando el uso del búfer alcanza un alto nivel), el MS vuelve a calcular la tasa de datos estimada que puede ser soportada y envía peticiones al UNC para ajustar la tasa de datos como corresponde. Tras recibir la petición, el UNC calcula la tasa ajustada de pérdida y envía la petición correspondiente de control de flujo en MS al SGSN conforme al estándar GPRS. El procedimiento de control de flujo basado en el MS a través de la interfaz Gb no se relata aquí, ya que está especificado ya en los estándares 3GPP correspondientes.

[0154] Inicialmente y antes de detectar la condición de control de flujo, la condición de control de flujo no existe en el MS. En este estado, el URLC del MS vigila la tasa de transferencia de datos descendente media y la utilización de recursos (por ejemplo el búfer de enlace descendente) y cuando la utilización sobrepasa un umbral determinado, se detecta una condición de control de flujo descendente.

[0155] Cuando se detecta la condición de control de flujo, el MS envía un mensaje URLC-DFC-REQ 2200 al UNC e inicia el temporizador URLC-DFC-TIMER, como se muestra en la figura 22. Cuando el temporizador llega al final, el MS verifica la condición de control de flujo descendente y si sigue existiendo, el MS reinicia el temporizador y opcionalmente envía otro mensaje URLC-DFC-REQ al UNC. El MS permanece en este estado mientras la condición de control de flujo persiste. Tan pronto se resuelve la condición de control de flujo, el MS desactiva el temporizador URLC-DFC-TIMER y hace una transición al estado estándar en el que no existe ninguna condición de control de flujo descendente.

[0156] Tras detectar la condición del control de flujo descendente, el MS inicia un procedimiento de control de flujo descendente enviando un mensaje URLC-DFC-REQ al UNC. Una realización de un mensaje URLC-DFC-REQ 2200 se muestra en la figura 23. Además de los IEs básicos, este formato de mensaje incluye un IE de petición de tasa de datos descendente del usuario que contiene una nueva tasa estimada de datos que puede soportarse. Al mismo tiempo, el MS inicia el temporizador URLC-DFC-TIMER para continuar vigilando la condición de control de flujo. El temporizador URLC-DFC-TIMER es un temporizador configurable. El MS envía esta petición al UNC a través de la conexión de señal TCP.

[0157] El mecanismo usado por el MS para detectar y vigilar la condición de control de flujo depende la implementación y por tanto no se especifica en este documento. Por ejemplo, la implementación puede estar basada en los bufers de enlace descendente, mantenidos y vigilados por el URLC en el MS. Cuando el uso del búfer sobrepasa un umbral (nivel superior), el MS inicia el procedimiento de control de flujo descendente e inicia el temporizador. El procedimiento de control de flujo está activo hasta que el nivel de utilización del búfer alcance el nivel inferior.

[0158] Tras recibir el mensaje URLC-DFC-REQ del MS, el UNC verifica que el TC URLC asociado con el MS esté activo y que la tasa actual de pérdidas del MS sea mayor de lo necesario. Asumiendo que la verificación se realiza con éxito, el UNC calcula la tase de pérdida correspondiente e inicia el procedimiento de control de flujo basado en el MS o en el PFC a través de la interfaz Gb conforme al estándar GPRS.

[0159] Cuando el URLC-DFC-TIMER caduca, el MS reevalúa la condición de control de flujo y realiza lo siguiente en base al resultado de dicha evaluación. Si la condición de control de flujo aún existe (por ejemplo, la utilización del búfer de enlace descendente sigue por encima del nivel bajo), el MS calcula una nueva tasa de datos que pueda ser soportada y reenvía el mensaje URLC-DFC-REQ correspondiente al UNC mediante la conexión de señal TCP. Al mismo tiempo, el MS inicia el temporizador URLC-DFC-REQ para continuar vigilando la transferencia de datos descendente. Si la condición de flujo se ha solucionado (por ejemplo estando la utilización del búfer por debajo del nivel inferior), el MS interrumpe el procedimiento de control de flujo.

CONTROL DE FLUJO DE ENLACE ASCENDENTE

[0160] El procedimiento de control de flujo de enlace ascendente se usa para gestionar de forma dinámica la distribución del ancho de banda de la interfaz Gb. El UNC implementa el algoritmo de control de flujo para vigilar y calcular la tasa de datos que puede soportarse por cada MS en base a las condiciones actuales. Cuando se detecta la condición de control de flujo de enlace ascendente (por ejemplo cuando el uso del búfer de enlace ascendente alcanza un alto nivel), el UNC vuelve a calcular la tasa de datos estimada que puede ser soportada y envía una petición correspondiente al MS para ajustar la tasa de datos de enlace ascendente como corresponde. Tras recibir la petición, el URLC en el MS inmediatamente ajusta la tasa de datos ascendente según la petición.

[0161] Inicialmente y antes de detectar la condición de control de flujo, la condición de control de flujo no existe en el UNC. En este estado, el URLC UNC vigila la tasa de transferencia de datos descendente media por cada MS y la utilización de recursos (por ejemplo el búfer enlace descendente) y cuando la utilización sobrepasa un umbral determinado, se detecta una condición de control de flujo descendente. Cuando se detecta la condición de control de flujo, el UNC envía un mensaje URLC-UFC-REQ 2400 al MS e inicia el temporizador URLC-UFC-TIMER, como se muestra en la figura 24. Cuando el temporizador llega al final, el UNC verifica la condición de control de flujo descendente y si sigue existiendo, el UNC reinicia el temporizador y opcionalmente envía otro mensaje URLC-UFC-REQ al MS. El UNC permanece en este estado mientras la condición de control de flujo persiste. Tan pronto se resuelve la condición de control de flujo, el UNC desactiva el temporizador URLC-UFC-TIMER y hace una transición al estado estándar en el que no existe ninguna condición de control de flujo descendente.

[0162] Tras detectar la condición del control de flujo descendente, el UNC inicia un procedimiento de control de flujo ascendente enviando un mensaje URLC-UFC-REQUEST 2400 al MS. Una realización de este mensaje se muestra en la figura 25. Además de los IEs básicos, este formato de mensaje que se muestra incluye un IE de petición de tasa de datos ascendente de usuario que contiene datos que identifican una nueva tasa máxima estimada de datos que puede soportarse. Al mismo tiempo, el UNC inicia el temporizador configurable URLC-UFC-TIMER para continuar vigilando la condición de control de flujo. El UNC mantiene sólo un URLC-UFC-TIMER por cada MS en el modo de control de flujo de enlace ascendente. El UNC el mensaje URLC-UFC-REQUEST al MS a través de la conexión de señal TCP.

[0163] El mecanismo usado por el UNC para detectar y vigilar la condición de control de flujo depende la implementación y por tanto no se especifica en este documento. Por ejemplo, la implementación puede estar basada en los bufers ascendentes, mantenidos y vigilados por el URLC en la MS. Habría un búfer por cada MS activa. Cuando el uso del búfer de enlace ascendente correspondiente sobrepasa un umbral (nivel superior), el UNC inicia el procedimiento de control de flujo ascendente para ese MS e inicia el temporizador URLC-UFC-TIMER. El procedimiento de control de flujo está activo para ese MS hasta que el nivel de utilización del búfer alcance el nivel inferior. Tras recibir el mensaje URLC-UFC-REQUEST del UNC, el MS inmediatamente ajusta la tasa de datos de enlace ascendente.

[0164] Cuando el URLC-UFC-TIMER caduca, el UNC reevalúa la condición de control de flujo y realiza lo siguiente en base al resultado de dicha evaluación. Si la condición de control de flujo aún existe ( por ejemplo, la utilización del búfer sigue por encima del nivel bajo), el UNC calcula una nueva tasa de datos ascendente que pueda ser soportada y reenvía el mensaje URLC-UFC-REQUEST correspondiente al MS mediante la conexión de señal TCP. Simultáneamente, el UNC inicia él para seguir vigilando la transferencia de datos de enlace ascendente asociada con el MS. Si la condición de flujo se ha resulta (p. ej. la utilización del búfer está por debajo del límite inferior), el UNC interrumpe el procedimiento de control de flujo y desactiva URLC-UFC-TIMER. En base a la implementación del algoritmo de control de flujo de enlace ascendente, el UNC puede aumentar gradualmente la tasa de datos de enlace ascendente usando el mismo mensaje URLC-UFC-REQ.

MODO NO CONFIRMADO UMA-RLC

[0165] El protocolo de modo no-confirmado UMA RLC proporciona el mecanismo para el envío de un mensaje no confirmado mediante la interfaz ascendente, usando el UDP. En una implementación, todos los mensajes del plano de usuario se transportan usando este servicio, a través del UDP, independientemente del modo RLC requerido por el LLC. Por lo general, el formato de mensaje es idéntico al del modo confirmado UMA RLC.

[0166] Mientras el TC URLC correspondiente esté disponible, tanto la estación móvil como el UNC pueden iniciar la transferencia de datos de usuario GPRS automáticamente usando el servicio URLC UNITDATA como se ilustra en la figura 26. Por ejemplo, en el paso A, un canal de transporte URLC está disponible. De acuerdo a esto, un mensaje URLC-UNITDATA 2600 puede ser enviado del MS al UNC (paso B) o un mensaje URLC-UNITDATA 2600 puede ser enviado del UNC al MS (paso B´). Los paquetes de datos de usuario GPRS se tunelan usando transporte UDP como se especifica en el canal de transporte URLC.

[0167] Un mensaje ejemplificado URLC-UNITDATA 2600 se muestra en la figura 27. Este formato de mensaje es sustancialmente el mismo que el mensaje URLC-DATA 1400 mostrado en la figura 15 y expuesto más arriba, con la diferencia primaria del valor del tipo de mensaje.

TRANSFERENCIA DE DATOS DE USUARIO GPRS DE ENLACE ASCENDENTE INICIADA POR EL MS

[0168] Asumiendo que el TC URLC ya ha sido activado, el URLC en el MS es capaz de reenviar inmediatamente cualquier paquete de datos de usuario GPRS ascendente al UNC. Tras recibir la petición del LLC de transferir un PDU LLC ascendente con los datos de usuario identificados en el LLC SAP 3, 5, 9 ó 11, el URLC MS reinicia el URLC-CHANNEL-TIMER, encapsula el PDU LLC completo dentro de un mensaje URLC-UNITDATA e incluye los siguientes parámetros: El IE TLLI se incluye como componente del encabezamiento URLC-UNITDATA; el IE de calidad de servicio y de información requerida se proporcionan por el LLC con la petición LLC PDU; la prioridad de radio se incluye como un componente del IE de calidad de servicio conforme a 3GPP TS 48.018 y el IE PFI se incluye si el componente de flujo de paquetes es soportado por el MS y por la red núcleo.

[0169] En consecuencia, el MS reenvía el mensaje URLC UNITDATA al UNC usando el TC URLC existente, es decir, usando la dirección IP del UNC y el número de puerto UDP correspondientes. Tras recibir el mensaje de datos de usuario de enlace ascendente de la MS, el UNC extrae el LLC PDU recibido y los parámetros de mensaje disponibles, determina el SGSN, el BVCI, la identidad de celda UMAN en servicio, incluyendo el RAI y construye el correspondiente PDU BSSGP-UL-UNIT-DATA. En consecuencia el UNC enlaza el PDU al SGSN mediante la interfaz Gb usando el procedimiento de enlace ascendente UNIT DATA en el BSSGP como en el estándar GPRS.

TRANSFERENCIA DE DATOS DE USUARIO GPRS DESCENDENTE INICIADA POR EL UNC

[0170] Asumiendo que el TC URLC ya ha sido activado, el URLC es capaz de reenviar inmediatamente cualquier paquete de datos de usuario GPRS descendente a la MS. Tras recibir un PDU BSSGP-DL-UNITDATA para la MS que contiene un PDU LLC de enlace descendente con datos de usuario GPRS identificado con LLC SAP 3,5,9 ó 11, el UNC encapsula el LLC PDU por completo dentro de un mensaje URLC-DATA e incluye los siguientes parámetros: un IE TLLI se incluye como componente del encabezamiento URLC-UNITDATA y un PFI se incluye si el componente de flujo de paquete es soportado por el MS y por la red núcleo. En consecuencia, el UNC reenvía el mensaje URLC UNITDATA al MS usando el TC URLC existente, es decir, usando la dirección IP del MS y el número de puerto UDP correspondientes. Tras recibir el mensaje de datos de usuario descendente del UNC, la MS URLC reinicia el URLC-CHANNEL-TIMER, extrae el PDU LLC recibido y el TLLI y reenvía el PDU a la capa LLC a través del SAP GRR conforme al estándar GPRS.

PROCEDIMIENTOS DE GESTIÓN DE ERRORES

[0171] Los procedimientos de gestión de errores relacionados con datos de protocolos UMA-RR y UMA-RLC desconocidos o erróneos coinciden con los procedimientos especificados en 3GPP TS 04.18, 3GPP TS 24.007 y 3GPP TS 24.008. Los escenarios de gestión de errores de protocolo UMA-RLC son aplicables tanto al transporte basado en TCP como al basado en UDP. Los errores se identifican por los mensajes correspondientes de estado UMA-RR-STATUS y URLC-STATUS. Un mensaje ejemplificado URLC-STATUS 2800 se muestra en la figura 28. Además de los IEs básicos, este mensaje incluye un IE de motivo URLC, con un valor correspondiente tal como se emplean en la tabla de valores de referencia URLC de la figura 10.

[0172] Si se recibe un mensaje demasiado corto para incluir todos los elementos obligatorios para el tipo de mensaje especificado, el mensaje es ignorado y descartado sin más. Esto se aplica tanto a mensajes UMA-RR como UMA-RLC. Si una estación móvil en modo UMA recibe un mensaje a través de UDP con un tipo de mensaje no definido para un PDU específico o no implementado, será ignorado y descartado sin más. Si una estación móvil en modo UMA recibe un mensaje por TCP con un tipo de mensaje no definido para un PDU específico o no implementado, devolverá un mensaje URR- o URLC-STATUS que incluye los siguientes IEs de causa: “Tipo de mensaje inexistente o no implementado” Si una estación móvil en modo UMA recibe un mensaje UMA-RR no compatible con el estado del protocolo, devolverá un mensaje URR-STATUS con la causa “ tipo de mensaje no compatible con el estado de protocolo” (si la conexión RR existe). Si una estación móvil en modo UMA recibe un mensaje UMA-RLC no compatible con el estado del protocolo, devolverá un mensaje URR-STATUS con la causa “tipo de mensaje no compatible con el estado de protocolo”. La misma lógica de procesos se aplica al UNC.

[0173] Si una estación móvil en modo UMA recibe un mensaje UMA-RR sin algún elemento obligatorio o sintácticamente incorrecto o fuera de la secuencia de información, el mensaje es ignorado y el MS devolverá un mensaje URR-STATUS incluyendo la causa “información obligatoria incorrecta” (si la conexión RR existe). Si una estación móvil en modo UMA recibe un mensaje UMA-RR o UMA RLC que contiene un IE desconocido, la estación ignorará ese elemento informativo y continuará con el procesamiento del mensaje. Si una estación móvil en modo UMA recibe un mensaje UMA-RLC sin algún elemento obligatorio o sintácticamente incorrecto o fuera de la secuencia de información, el mensaje es ignorado y el MS devolverá un mensaje URLC-STATUS incluyendo la causa “mensaje sintácticamente incorrecto”. Si una estación móvil en modo UMA recibe un mensaje UMA-RR con contenidos semánticos incorrectos, ignorará el mensaje y devolverá un mensaje URR-STATUS con la causa “ mensaje sintácticamente incorrecto” (si la conexión RR existe). La misma lógica de procesos se aplica a un UNC.

ARQUITECTURA DEL UNC

[0174] Un diagrama de bloques que ilustra una arquitectura de alto nivel correspondiente a una realización de un UNC se muestra en la figura 29. En el corazón de la arquitectura de UNC se encuentra un controlador de red interior (INC por sus siglas inglesas en lo sucesivo). En general, el INC realiza operaciones similares a las descritas anteriormente para el UNC. Sin embargo, como se muestra en la arquitectura de UNC ya expuesta, un servidor de pasarela de enlace de seguridad integrado está incluido, así como una pasarela de medios que es controlada por el INC. En consecuencia, cada uno de estos elementos se muestra como un elemento independiente que se emplea para facilitar diversos aspectos de las operaciones del UNC descritas en este documento.

[0175] En general, el UNC puede proporcionar uno o más puertos de comunicación para apoyar las comunicaciones entre terminales móviles y el UNC (por ejemplo, a través de un AP 128 y de una red de banda ancha IP 138, como se muestra en la figura 1). Por ejemplo en la realización ilustrada en la figura 29, la seguridad del servidor de pasarela de enlace 2902 se encuentra asociada a la red IP 138 a través de un puerto IP 2906. Además, los puertos IP 2908 y 2910 se utilizan para conectar el INC 2900 y la pasarela de medios 2904 con el servidor de pasarela de enlace de seguridad.

[0176] El servidor de pasarela de enlace de seguridad 2902 realiza servicios de seguridad y autentificación. Puede ser una unidad integrada (como se muestra), o puede ser una unidad independiente (física) conectada al UNC a través de un enlace de comunicación adecuado. Del mismo modo, la pasarela de medios 2904, que sirve de pasarela de medios para servicios de voz proporcionados por el núcleo de la red, puede abarcar una unidad integrada (como se muestra) o una unidad separada relacionada con el INC y los servidores de seguridad de pasarela de enlace a través de enlaces apropiados de comunicación.

[0177] El INC incluye recursos para apoyar (es decir, generar y procesar) los mensajes de interfaz ascendente descritos en este documento. Estos recursos se representan como lógica de interfaz ascendente (I/F). Del mismo modo, el INC incluye lógica de interfaz SGSN 114 para soportar las comunicaciones con SGSN a través de un puerto Gb, y lógica de interfaz MSC 110 para apoyar la comunicación con MSC a través de un puerto SS7. Mientras tanto, la pasarela de medios incluye lógica de interfaz MSC para apoyar la comunicación con MSC 110 a través de un puerto TDM. Cada lógica de interfaz ascendente, de interfaz SGSN, y de interfaz MSC puede ser implementada a través de la ejecución de software, hardware integrado / programado o una combinación de los dos. Por ejemplo, la lógica de la interfaz ascendente puede ser facilitada con la ejecución de uno o más módulos de software en un procesador, donde los módulos de software están codificados para generar y/o procesar mensajes URR.

[0178] En general, un UNC podrá estar implementado por un solo servidor, varios servidores distribuidos y varios servidores en clúster. Por ejemplo, un único servidor puede ser empleado para ejecutar varias aplicaciones de software para proporcionar las distintas funciones mostradas en el diagrama de bloques de la arquitectura UNC de la figura 29. Opcionalmente, algunas de las funciones, tales como las funciones de pasarela de seguridad del servidor y/o funciones de pasarela de medios, pueden ser proporcionadas por un servidor independiente o varios servidores. En otra configuración se emplea un servidor blade. El servidor blade incluye múltiples servidores que están instalados en un bastidor o chasis común, donde cada servidor funciona como un servidor independiente, contando cada uno con su(s) propio(s) procesador(es), memoria e interfaces de red. En una realización, las funciones proporcionadas por cada uno de los servidores de pasarela de seguridad, de INC y pasarela de medios se facilitan a través de la ejecución de aplicaciones de software y/o módulos en servidores blade respectivamente.

ARQUITECTURA DE LA ESTACIÓN MÓVIL

[0179] La figura 30 muestra un diagrama de bloques que ilustra una arquitectura de alto nivel para una realización de una estación móvil. La arquitectura incluye un procesador 3000 junto con una memoria no volátil 3002, un subsistema de antena RAN de licencia 3004 y un subsistema de antena RAN sin licencia 3006. La memoria no volátil 3002 se utiliza para almacenar instrucciones de software/firmware para la realización de diversas funciones y operaciones que se describen en este documento. Estas funciones y operaciones son la lógica de la interfaz RAN de licencia 3008 mostrada, la lógica de la interfaz WLAN 3010 y la lógica de interfaz ascendente 3012.

[0180] Un subsistema de antena RAN de licencia 3004 y una lógica de interfaz de sistema RAN con licencia 3008 se emplean para facilitar las operaciones convencionales de RAN con licencia. Por ejemplo en una realización, el sistema RAN de licencia abarca una red GSM, por lo que estos componentes facilitan las operaciones normales de la red GSM empleadas normalmente por los dispositivos móviles basados en GSM y similares, que son bien conocidos en el arte de la comunicación con dispositivos celulares. Mientras tanto, el sistema de antena RAN sin licencia 3006 y la lógica de interfaz WLAN 3010 se utilizan para apoyar un canal inalámbrico sin licencia (es decir, un enlace) 136 con un punto de acceso 128 a través del cual se puede acceder a los servicios UMAN. En general, estos bloques representan los componentes convencionales y la lógica empleada para apoyar las comunicaciones a través de un enlace WLAN sin licencia. Por ejemplo, estos componentes son ilustrativos de los componentes que se pueden emplear para implementar las capas inferiores de Bluetooth mostradas en la figura 3B de un enlace Bluetooth, o las capas inferiores 802.11 que se muestran en la figura 3C para un enlace de tipo 802.11.

[0181] La lógica de interfaz ascendente 3012 se utiliza para proporcionar las funciones de interfaz ascendente del terminal móvil y las operaciones descritas en este documento. Esto incluye la generación y el procesamiento de varios mensajes URR, así como proporcionar las capas de varias interfaces ascendentes tal y como se muestra en las figuras 3A y 3D-F.

[0182] Como se mencionó anteriormente, los formatos de los distintos mensajes descritos aquí son ejemplares. Sin embargo, cada mensaje debe incluir un conjunto básico de elementos de información, incluyendo un diferenciador de protocolo, un indicador de salto, y una identidad de mensaje. La inclusión de un elemento de información UCI como IE base se muestra en formatos de mensaje ejemplares ilustrados en este documento, sin embargo, el IE UCI u otro IE similar para indicar si un mensaje es un primer mensaje, otro tipo de mensaje o un mensaje para casos de emergencia no son necesarios, pudiendo facilitarse esta funcionalidad por otros medios, como manteniendo la información adecuada sobre el estado los dispositivos de comunicación (es decir, terminales móviles y UNCs).

[0183] De acuerdo a una posible implementación, la delimitación del mensaje a través de un transporte en streaming (por ejemplo, TCP) se lleva a cabo por el transporte subyacente. En consecuencia, no hay necesidad de incluir un elemento de información que especifique la longitud de un formato de mensaje de longitud variable. Sin embargo, esto no significa que sean limitativos, ya que el uso de un elemento de información para especificar la longitud de un mensaje es una opción contemplada a menudo por los inventores como otro medio para delimitar los mensajes emitidos en streaming.

[0184] Los formatos de los diversos elementos de información también son simplemente ejemplares. Por ejemplo, un determinado conjunto de información se puede proporcionar a través de un solo IE o por medio de múltiples IEs. Además, la información contenida en los IEs descritos aquí se puede organizar en otros formatos y/o agrupar en maneras alternativas. [0185] Los medios para facilitar la generación de mensajes diversos y operaciones de procesamiento, así como diversos aspectos de la interfaz ascendente pueden incluir la ejecución de instrucciones de software/firmware en un elemento de procesamiento apropiado, tal como, pero no limitado a, un procesador, procesadores múltiples, uno de varios procesador multi-núcleo, un microcontrolador, etc. Por lo tanto, las realizaciones de esta invención pueden ser utilizadas como o para apoyar las instrucciones ejecutadas en alguna forma de núcleo de procesamiento o que se lleven a cabo o se ejecuten dentro de un medio legible por máquina. Un medio legible por máquina incluye cualquier mecanismo para almacenar o transmitir información en un formato legible por una máquina (por ejemplo, un ordenador). Por ejemplo, un soporte legible por máquina, puede incluir una memoria de sólo lectura (ROM), una memoria de acceso aleatorio (RAM), un disco magnético de almacenamiento, un medio de almacenamiento óptico y un dispositivo de memoria flash, etc. Además, un medio legible por máquina, puede incluir señales que se propagan de forma eléctrica, óptica, acústica o de otro tipo de señales propagadas (por ejemplo, ondas portadoras, señales infrarrojas, señales digitales, etc.). Por ejemplo, en una implementación prevista, instrucciones implementadas como actualizaciones de software para facilitar la mensajería UMA se pueden descargar a un dispositivo móvil a través de un enlace inalámbrico, como un enlace UMAN o un enlace GSM.

[0186] La descripción anterior de realizaciones ilustradas de la invención no tiene la intención de ser exhaustiva o limitante a las formas de la invención divulgadas. Por un lado las realizaciones específicas y los ejemplos de la invención que se describen en este documento sirven a fines ilustrativos; siendo posibles modificaciones equivalentes, como los expertos en la materia podrán reconocer.

[0187] Estas modificaciones se pueden aplicar a la invención a la luz de la descripción detallada arriba. Los términos utilizados en las siguientes reivindicaciones no deben ser interpretados como que limitan la invención a las formas de realización específicas descritas en la descripción y en los dibujos. Más bien, el alcance de la invención estará determinado en su totalidad por las siguientes reivindicaciones.

APÉNDICE I: TABLA DE ACRÓNIMOS

[0188]

AP: Access point (punto de acceso)

ARFCN: Absolute RF Channel Number (Nr. de canal absoluto de radiofrecuencia)

ATM: Asynchronous Transfer Mode (Modo de transferencia asíncrona)

ATM VC: ATM Virtual Circuit (Circuito virtual en ATM)

BA: BCCH Allocation (Asignación BCCH)

BAS: Broadband Access System (Sistema de acceso de banda ancha)

BB: Broadband (Banda ancha)

BCCH: Broadcast Common Control Channel (Canal de control de banda ancha)

BRAS: Broadband Remote Access System (Sistema de acceso remoto de banda ancha)

BSC: Base Station Controller (Controlador de estación base)

BSS: Base Station Sub-System (Subsistema de estación base)

BSSGP: Base Station System GPRS Protocol (Protocolo GPRS del sistema de la estación base)

BSSMAP: Base Station System Management Aplication Part (Parte de aplicación de gestión del sistema de estación base)

BTS: Base Transceiver Station (Estación trasnceptora base)

CDMA: Code Division Multiple Access (Acceso múltiple por división de códigos)

CGI: Cell Global Identification (Identificación global de celda)

CIC: Circuit Identity Code (Código de identidad de circuito)

CLIP: Calling Line Presentation (Presentación de la línea de llamada)

CM: Connection Management (Gestión de conexión)

CPE: Customer Premises Equipment (Equipamiento de instalaciones del cliente)

CS: Circuit Switched (Circuito conmutado)

CVSD: Continuous Variable Slope Delta Modulation (modulación delta de gradiente continuamente variable)

DSL: Digital Subscriber Line (Línea de abonado digital)

DSLAM: DSL Access Multiplexer (Multiplicador de acceso DSL)

DTAP: Direct Transfer Application Part (Parte de aplicación de transferencia directa)

ETSI: European Telecommunications Standards Institute (Instituto Européo de Estándares de Telecomunicaciones)

FCAPS: Fault Management, Configuration, Accounting, Performance and Security (Gestión de fallos, configuración, contabilización, rendimiento y seguridad)

FCC: US Federal Communications Commission (Comisión de Comunicaciones de EE.UU.)

GERAN: GSM Edge Radio Access Network (Red de acceso por radio GSM/EDGE)

GGSN: Gateway GPRS Support Node (Nodo de soporte de la pasarela GPRS)

GMM/SM: GPRS Mobility Management and Session Management (Gestión de movilidad y sesión GPRS)

GMSC: Gateway MSC (Pasarela MSC)

GSM: Global System for Mobile Communication (Sistema global de comunicación móvil)

GPRS: General Packet Radio Service (Servicio general de paquetes por radio)

GSN: GPRS Support Node (Nodo de soporte GPRS)

GTP: GPRS Tunneling Protocol (Protocolo de tunel GPRS)

HLR: Home Location Register (Registro de ubicación base)

IAN: Indoor Access Network (see also UMA cell) (Red de acceso interior (véase también celda UMA)

IAN-RR: Indoor Access Network Radio Ressource Management (Gestión de recursos de radio de red de acceso interior)

IBS: Indoor Base Station (Estación base interior)

IBSAP: IBS Aplication Protocol (Protocolo de aplicación IBS)

IBSMAP: IBS Management Application Protocol (Protocolo de aplicación de gestión IBS)

IEP: IAN Encapsulation Protocol

IETF: Internet Engineering Task Force (Grupo de trabajo de ingeniería de internet)

IMEI: International Mobile Station Equipment Identity (Identidad internacional del equipo de la estación móvil)

IMSI: International Mobile Subscriber Identity (Identidad internacional de abonado móvil)

INC: Internet Network Controller (Controlador de red de internet)

IP: Internet Protocol (Protocolo de internet)

ISDN: Integrated services digital network (Red integral de servicios digitales)

ISP: Internet Service Provider (Proveedor de servicios de internet)

ISP IP: Internet Service Provider IP (Dirección Ip del proveedor de servicios de internet)

IST: IAN Secure Tunnel (Tunel seguro IAN)

ISUP: ISDN User Part (Parte del usuario de red ISDN)

ITP: IAN Transfer Protocol (Protocolo de transferencia IAN)

LA: Location Area (Area de ubicación)

LAI: Location Area Identification (Identificaión de área de ubicación)

LLC: Logical Link Control (Control de enlace lógico)

MAC: Medium Access Control (Control de acceso a medio)

MAP: Mobile Application Part (Parte de la aplicación móvil)

MDN: Mobile Directory Number (Número de directorio móvil)

MG: Media Gateway (Pasarela de medios)

MM: Mobility Management (Gestión de la movilidad)

MS: Mobile Station (Terminal/Estación móvil)

MSC: Mobile Switching Center (Centro de conmutación móvil)

MSISDN: Mobile Station International ISDN Number (Nr. Internacional ISDN de la estación/terminal móvil)

MSRN: Mobile Station Roaming Number (Numero de itinerancia de la estación/terminal móvil)

MTP1: Message Transfer Part Layer 1 (Capa 1 de la parte/pieza de transferencia de mensaje)

MTP2: Message Transfer Part Layer 2 (Capa 2 de la parte/pieza de transferencia de mensaje)

MTP3: Message Transfer Part Layer 3 (Capa 3 de la parte/pieza de transferencia de mensaje)

NAPT: Network Adress and Port Translation (Traducción de puerto y dirección de red)

NAT: Network Adress Translation (Traducción de dirección de red)

NS: Network Service (Servicio de red)

PCM: Pulse Code Modulation (Modulación por impulsos codificados)

PCS: Personal communication Services (Servicios de comunicaciones personales)

PLMN: Public Land Mobile Network (Red móvilpública terrestre)

POTS: Plain Old Telephone Service (Plain Old Telephone Service (Servicio telefónico ordinario antiguo)

PPP: Point-to-point protocol (Protocolo punto-a-punto)

PPPoE: PPP over Ethernet (PPP por ethernet)

PSTN: Public Switched Telephone Network (Red pública conmutada de teléfono)

P-TMSI: Packet Temporary Mobile Subscriber Identity (Identidad de paquetes temporales de abonado)

QoS: Quality of Service (Calidad de servicio)

RA: Routing Area (Área de enrutamiento)

RAC: Routing Area Code(Código de área de enrutamiento)

RAI: Routing Area Identity (Identidad de área de enrutamiento)

RAN: Radio Access Network (Red de acceso por radio)

RF: Radio Frequency (Radiofrecuencia)

RFC: Request for Comment (IETF Standard) (Petición de comentarios, estándar del IETF)

RLC: Radio Link Control (Control de enlace de radio)

RR: Radio Ressource Management (Gestión de recursos de radio)

RTCP: Real Time Control Protocol (Protocolo de control de tiempo real)

RTP: Real Time Protocol (Protocolo de tiempo real)

SAP: Service Access Point (Punto de acceso de servicio)

SCCP: Signaling Connection Control Part (Parte de control de la conexión de señal)

SCO: Synchronous Connection-Oriented (Orientado a conexión síncrona)

SDCCH: Standalone Dedicated Control Channel (Canal de control aislado dedicado)

SGSN: Serving GPRS Support Node (Nodo de soporte del GPRS en servicio)

SMS: Short Message Service (Servicio de mensajes cortos)

SM-SC: Short Message Service Centre (Centro para servicio de mensajes cortos)

SMS-GMSC: Short Message Service Gateway MSC (Centro de conmutación móvil de pasarela de servicios de mensajes cortos)

SMS-IWMSC: Short Message Service Interworking MSC (Centro de conmutación móvil de interconexión de servicios de mensajes cortos)

SNDCP: Subnetwork Dependent Convergence Protocol (Protocolo de convergencia dependiente de subredes )

SS: Supplementary Service (Servicio suplementario)

SSL: Secure Socket Layer (Capa de conexión segura)

TCAP: Transaction Capabilities Application Part (Parte de aplicación de capacidad de transacción)

TCP: Transmission Control Protocol (Protocolo de control de transmisión)

TLLI: Temporary Logical Link Identity (Identidad de enlace lógico temporal)

TMSI: Temporary Mobile Subscriber Identity (Identidad del abonado móvil temporal)

TRAU: Transcoder and Rate Adaptation Unit (Unidad de transcodificación y adaptación de velocidad)

TTY: Text telephone or teletypewriter (Teléfono de texto o teletipo)

UDP: User Datagram Protocol (Protocolo de datagrama de usuario)

UMA Cell: Unlicensed Mobile Access Cell (see also IAN)(Celda de acceso móvil sin licencia , véase también IAN)

UMTS: Universal Mobile Telecommunications System (Sistema universal de telecomunicaciones móviles)

UNC: UMA Network Controller (see also INC) (Controlador de red UMA, véase también INC)

VLR: Visited Location Register (Registro de ubicaciones visitadas)

VMSC: Visited MSC (Controlador de estación/terminal móvil visitado)

WLAN: Wireless Local Area Network (Red de área local inalámbrica)

WSP IP: Wireless Service Provider's IP Network (Red IP del proveedor de servicios inalámbricos)

Claims

REIVINDICACIONES

1. Un método para facilitar servicios de datos para una estación móvil, MS, (102) en una red de acceso móvil sin licencia, UMAN, siendo dicha estación móvil operable en la UMAN y en una red inalámbrica de licencia y abarcando el método:

-

establecer una conexión dedicada entre el MS y la UMAN a través de un controlador de red (UNC) de acceso

móvil sin licencia (UMA); -establecer una sesión de protocolo de control de transmisión, TCP, entre la MS y el UNC (paso A); -enviar mensajes UMA de control de radioenlace, URLC, entre la MS y el UNC para facilitar servicios de datos

(pasos B y C), incluyendo cada mensaje URLC -un diferenciador de protocolo (1400); -un indicador de salto y -un tipo de mensaje a través del cual el mensaje correspondiente se puede identificar (1400) y transferir

señales de servicio general de paquetes vía radio, GPRS, o de servicio de mensajes cortos, SMS, entre la MS y el UNC usando un mensaje URLC-DATA, incluyendo el mensaje URLC DATA (1400) una unidad de control de enlace lógico para paquetes de datos, LLC PDU, que contiene los datos a transferir.
2.

El método de la reivindicación 1, incluyendo el mensaje URLC DATA un elemento necesario de información de calidad del servicio, IE, que define un nivel de transferencia usado para realizar una operación de transferencia de datos.
3.

El método de la reivindicación 1, incluyendo el mensaje URLC DATA además un elemento necesario de información de prioridad de radio, IE, que solicita una priorización relativa del mensaje.
4.

El método de la reivindicación 1, incluyendo además el mensaje URLC-DATA un elemento de información, IE, de identificador temporal de enlace lógico TLLI.
5.

El método de la reivindicación 1, incluyendo el mensaje URLC DATA un elemento necesario de información de identificación de flujo de paquetes, IE, que identifica un flujo de paquetes correspondiente a una transferencia de datos.
6.

Un controlador de red UNC (140) en acceso móvil sin licencia, UMA, para operar en una red UMA, UMAN, que

comprende una primera red de acceso por radio, el UNC abarcando: -una primera interfaz de red que abarca una interfaz de red (322A) de protocolo de internet, IP; -una segunda interfaz de red con una interfaz ascendente a través de la cual los mensajes UMA se deben

transmitir y recibir a/de una estación móvil, MS, a través de un punto de acceso (128) conectado comunicativamente entre el MS y el UNC, incluyendo la interfaz ascendente una pluralidad de capas implementadas sobre la interfaz de red IP (204, 306, 318, 320);

-

una tercera interfaz de red a través de la que el UNC puede estar conectado a una red núcleo que es accesible a una red de acceso inalámbrico por radio con licencia (300-304);

-

medios para generar y/o procesar una pluralidad de mensajes UMA de control de enlace de radio, URLC, transmitidos a través de la interfaz ascendente para prestar servicios de datos (pasos B y C), incluyendo cada mensaje URLC un conjunto de elementos de información básicos incluyendo un

-diferenciador de protocolo (1400); -un indicador de salto y -un tipo de mensaje mediante el cual se puede procesar el mensaje correspondiente (1400); -medios para procesar el mensaje URLC DATA recibido del MS (paso B), incluyendo el mensaje URLC DATA

una unidad encapsulada de datos en paquetes para el control del enlace lógico, LLC PDU, abarcando datos transferidos desde la red núcleo a través del UNC (1400) y

-

medios para generar un mensaje URLC DATA mediante los que enviar datos a la MS (paso 14), incluyendo el mensaje URLC DATA una unidad encapsulada de datos en paquetes para el control del enlace lógico, LLC PDU, conteniendo los datos (1400).
7. Una estación móvil, MS, que abarca: -una primera interfaz inalámbrica (122) para acceder a una primera red inalámbrica de acceso por radio con licencia;

-

una segunda interfaz inalámbrica (136) para acceder a una segunda red de acceso por radio, abarcando una red de acceso móvil sin licencia, UMAN, a través de un punto de acceso, AP, (128) usando una frecuencia de radio sin licencia;

-

un interfaz ascendente para comunicar con la UMAN a través de un controlador de red, UNC, en un acceso móvil sin licencia, UMA, el cual está conectado comunicativamente al AP mediante una red (322) de protocolo de internet, IP;

-

medios para generar y/o procesar una pluralidad de mensajes de control por radio UMA, URLC, transmitidos

mediante la interfaz ascendente para prestar servicios de datos, -incluyendo cada mensaje URLC un conjunto de elementos de información básicos, IEs, incluyendo -un diferenciador de protocolo (1400);

-

un indicador de salto y -un tipo de mensaje a través del cual el mensaje correspondiente es identificado (1400) y -medios para procesar el mensaje URLC DATA recibido en la MS desde un UNC (paso C), incluyendo el

mensaje URLC DATA (1400) una unidad encapsulada de datos en paquetes para el control del enlace lógico, LLC PDU, abarcando datos transferidos desde la red núcleo a través del UNC (1400) y

-

medios para generar un mensaje URLC DATA mediante los que enviar datos a la red núcleo a través del UNC (paso B), incluyendo el mensaje URLC DATA una unidad encapsulada de datos en paquetes para el control del enlace lógico, LLC PDU, conteniendo los datos (1400).
8. Un programa de ordenador que implementa el método de alguna de las reivindicaciones 1 a 5.