MXPA02009502A - Metodo y aparato para aplicarse a una estacion movil para identificar eventos especificos. - Google Patents

Abstract

La presente invencion describe un metodo y un aparato para una aplicacion de estacion movil para identificar eventos especificos en un sistema de comunicacion inalambrico. La presente invencion incluye una interconexion de programa de aplicacion (API) que facilita las comunicaciones entre una pila del protocolo de comunicacion de estacion movil, que se comunica con una red de comunicacion, y una aplicacion de estacion movil. La API permite al menos uno de los eventos especificos sobre la base de su estado. La aplicacion de la estacion movil identifica entonces los eventos especificos que son permitidos.

Description

-MÉTODO Y APARATO PARA APLICARSE A UNA ESTACIÓN MÓVIL PARA IDENTIFICAR EVENTOS ESPECÍFICOS ANTECEDENTES 1. Campo de la Invención Esta invención se relaciona de manera general con el campo de las comunicaciones inalámbricas. De manera más particular, la presente invención se relaciona con un método y aparato novedosos que permiten la aplicación de una estación móvil para la identificación de eventos específicos en un sistema de comunicación inalámbrico. 2. Descripción de la Técnica Relacionada A. Comunicaciones Inalámbricas Recientes innovaciones en la comunicación inalámbrica y tecnologías relacionadas con computadoras, asi como el crecimiento sin precedente de los abonados de Internet, ha pavimentado el camino para la computación móvil. En efecto, la popularidad de la computación móvil ha colocado mayores demandas sobre la infraestructura de la Internet actual para proporcionar a los usuarios móviles más soporte. El alma de esta infraestructura es el Protocolo de Internet orientado a paquetes (IP^ el cual proporciona varios servicios, incluyendo el direccionamiento y encaminamiento de paquetes (datagramas) entre redes de área local y amplia (LAN y WAN) . El protocolo IP es definido en la Petición de Comentarios 791 (RFC 791) titulada, "ESPECIFICACIÓN DEL PROTOCOLO DEL PROGRAMA DE INTERNET DARPA PARA EL PROTOCOLO DE INTERNET", fechado en Septiembre de 1981. El protocolo IP es un protocolo de red que encapsula datos en paquetes IP para su transmisión. La información de direccionamiento y encaminamiento es fijada al encabezado del paquete. Los encabezados de IP, por ejemplo, contienen direcciones de 32 bits que identifican a los anfitriones emisores y receptores. Esas direcciones son utilizadas por encaminadores intermedios para seleccionar una trayectoria a través de la red para el paquete hacia su destino final a la dirección pretendida. De este modo, el protocolo IP permite que paquetes que se originan en cualquier nodo de la Internet en el mundo sean encaminados a cualquier otro nodo en la Internet en el mundo. Por otro lado, se utiliza una capa de transporte, la cual comprende un Protocolo de Control de Transmisión (TCP) o un Protocolo de Datagramas del Usuario (UDP), para dirigir aplicaciones particulares. La tendencia actual es que los usuarios móviles utilicen computadoras móviles, tales como computadoras portátiles o de mano, en conjunto con dispositivos de comunicación inalámbricos, como teléfonos celulares o portátiles, para tener acceso a la Internet. Es decir, al igual que los usuarios emplean convencionalmente dispositivos de comunicación "alámbricos" para conectar sus computadoras a redes con base en tierra, los usuarios móviles utilizarán dispositivos de comunicación inalámbricos, comúnmente referidos como "estaciones móviles" (MS), para conectar sus terminales móviles a esas redes. Como se utiliza aqui, la estación móvil o MS se referirá a cualquier estación de abonado o suscriptor en la red de radio inalámbrica pública. La FIGURA 1 (Técnica Anterior) ilustra un diagrama de bloques de alto nivel de un sistema de comunicación de datos inalámbrico en el cual la MS 110 se comunica con una Función de Interconexión (IWF) 108 via un Centro de Conmutación de Estación Base/Móvil (BS/MSC) 106. La I F 108 sirve como el punto de acceso a la Internet. La IWF 108 se acopla a, y con frecuencia se colocaliza con, el BS/MSC 106, el cual puede ser una estación base inalámbrica convencional como es sabido en la técnica. Otro protocolo estándar que dirige el sistema de comunicación de datos inalámbrico es el Proyecto de Sociedad de la 3ra Generación 2 ("3GPP2") titulado "ESTÁNDAR DE RED IP INALÁMBRICA", publicado en Diciembre de 1999. El Estándar de Red IP Inalámbrico 3G, por ejemplo, incluye un Nodo de Servicio de Datos de Paquete ("PSDN"), que funciona igual que la IWF 108. Existen varios protocolos que dirigen las comunicaciones de datos entre la MS 110 y la I F 108. Por ejemplo, el Estándar Interino de la Asociación de la Industria de las Telecomunicaciones (TÍA) /Asociación de Industrias Electrónicas (EIA) IS-95, titulado "ESTÁNDAR DE COMPATIBILIDAD DE ESTACIÓN MOVIL-ESTACION BASE PARA SISTEMA CELULAR DE ESPECTRO EXTENDIDO DE BANDA ANCHA DE DOBLE MODO", publicado en Julio de 1993, proporciona de manera general un estándar para sistemas de comunicación inalámbricos de espectro extendido de banda ancha. Además, el estándar TIA/EIA IS-707.5, titulado "OPCIONES DE SERVICIO DE DATOS PARA SISTEMAS DE ESPECTRO EXTENDIDO DE BANDA ANCHA: SERVICIOS DE DATOS DE PAQUETE", publicado en Febrero 1998, definen los requerimientos para el soporte de la capacidad de transmisión de datos de paquete en sistemas TIA/EIA IS-95 y especifica los servicios portadores de datos de paquete que pueden ser utilizados para la comunicación entre la MS 110 y la IWF 108 via el BS/MSC 106. También, el estándar TIA/EIA IS-707-A.5 titulado "OPCIONES DE SERVICIO DE DATOS PARA SISTEMAS DE ESPECTRO EXTENDIDO: SERVICIOS DE DATOS DE PAQUETE"" y el estándar TIA/EIA IS-707-A.9 titulado "SERVICIO DE DATOS PARA SISTEMAS DE ESPECTRO EXTENDIDO: SERVICIOS DE DATOS DE PAQUETE DE ALTA VELOCIDAD" , ambos publicados en Marzo de 1999, también definen requerimientos para soportar la transmisión de datos de paquete en sistemas TIA/EIA IS-95. Además, otro protocolo estándar que dirige comunicaciones entre la MS 110 y la IWF 108 es el TIA/EIA IS-2000 titulado "INTRODUCCIÓN A ESTÁNDARES CDMA 2000 PARA SISTEMAS DE ESPECTRO EXTENDIDO", publicado en Julio de 1999. El IS-707.5 introduce modelos de opción de protocolo de comunicación entre la MS 110 y el BS/MSC 106 (la interconexión Um) , y entre el BS/MSC 106 y el IWF 108 (la interconexión L) . Por ejemplo, un Modelo de Relé representa la situación en donde existe un enlace de Protocolo Punto a Punto (PPP) en la interconexión Um entre la MS 110 y la IWF 108. El protocolo PPP es descrito con detalle en la Petición de Comentarios 1661 (RFC 1661), titulada "PROTOCOLO PUNTO A PUNTO (PPP)". La FIGURA 2 (Técnica Anterior) es un diagrama de las pilas de protocolo en cada entidad del Modelo de Relé IS-707.5. En el lado izquierdo lejano de la figura se encuentra una pila de protocolo de comunicación, mostrada en formato vertical convencional, que muestra las capas del protocolo que funcionan en la MS 110. La pila del protocolo de la MS 110 es ilustrada como si estuviera colocada lógicamente a la pila del protocolo del BS/MSC 106 sobre la interconexión Um. La pila del protocolo del BS/MSC 106, a su vez, ilustrada como si estuviera conectada lógicamente a la pila del protocolo de la I F 108 sobre la interconexión L. La operación descrita en la Figura 2 es como sigue: una entidad de protocolo de la capa superior 200, tal como un programa de aplicación que funciona en la MS 110, tiene la necesidad de enviar datos sobre la Internet. Una aplicación representativa puede ser un programa navegador de red (por ejemplo, Netscape NavigatorMR, Microsoft Internet ExplorerMR) . El navegador de la red solicita un Asignador de Recursos Universal (URL), tal como el HIPERENLACE "http: //www. Qualcomm. com/" . Un protocolo de Sistema de Nombre de Dominio (DNS) , también en el protocolo de la capa superior 200, traduce el nombre de un huésped textual www. Qualcomm. com a una dirección numérica de 32 bits IP por el uso de una resolución de nombre de dominio, que traduce los nombres a direcciones en la Internet. El Protocolo de Transferencia de Hipertexto (HTTP) , el cual también es un protocolo de la capa superior 200, construye un mensaje de OBTENER (GET) para el URL solicitado, y especifica que será utilizado el TCP para enviar el mensaje y para operaciones del HTTP. La capa de transporte 202 utiliza el puerto 80, el cual es conocido en la técnica como el puerto de destino para encaminar las operaciones del HTTP a la aplicación. El protocolo TCP, el cual es un protocolo de la capa de transporte 202, abre una conexión a la dirección IP especificada por el DNS y transmite el mensaje de OBTENER HTTP al nivel de aplicación. El protocolo TCP especifica que protocolo IP será utilizado para el transporte del mensaje. El protocolo IP, el cual es un protocolo de la capa de la red 204, transmite los paquetes TCP a la dirección IP especificada. El PPP, el cual es un protocolo de la capa de enlace 206, codifica los paquetes del IP y los transmite al protocolo de la capa de relevo 208. Un ejemplo del protocolo de la capa de relevo 208 puede ser el estándar TIA/EIA-232F ilustrado, el cual se define en "INTERCONEXIÓN DE DATOS ENTRE EQUIPO TERMINAL Y El EQUIPO QUE TERMINA El CIRCUITO DE DATOS EMPLEANDO INTERCAMBIO DE DATOS BINARIOS EN SERIE", publicado en Octubre de 1997. Debe comprenderse que pueden ser utilizados otros estándares o protocolos conocidos por los expertos en la técnica para definir la transmisión a través de las capas. Por ejemplo, otros estándares aplicables pueden incluir la "ESPECIFICACIÓN DEL CANAL EN SERIE UNIVERSAL (USB), Revisión 1.1", publicada en Septiembre de 1998, y el "NÚCLEO DE LA VERSIÓN 1.0A DE LA ESPECIFICACIÓN DE BLUETOOTH", publicado el Julio de 1999. Finalmente, el protocolo de la capa de relevo 208 pasa los paquetes PPP a un Protocolo de Enlace de Radio (RLP) 210, y a continuación al protocolo IS-95 212, para la transmisión al BS/MSC 106 sobre la interconexión Um. El protocolo RLP 210 es definido en el estándar IS- 707.2, titulado "OPCIONES DE SERVICIO DE DATOS PARA SISTEMAS DE ESPECTRO EXTENDIDO DE BANDA ANCHA: PROTOCOLO DE ENLACE DE RADIO", publicado en Febrero de 1998, y el protocolo IS-95 es definido en el estándar IS-95 identificado anteriormente. Un protocolo de capa de relevo complementario 220 sobre el BS/MSC 106 recibe paquetes PPP sobre la interconexión Um a través de una capa IS-95 218, y a continuación una capa de RLP 216. El protocolo de la capa de relevo 220 pasa ello sobre la interconexión L a un protocolo de la capa de relevo 228 sobre la IWF 108. Una capa de enlace del protocolo PPP 226 sobre la IWF 108 recibe los paquetes PPP de protocolo de la capa de relevo 228, y termina la conexión PPP entre la MS 110 y la IWF 108. Los paquetes son pasados de la capa PPP 226 a una capa IP 224 sobre la IWF 108 para el examen del encabezado del paquete IP para su encaminamiento final, el cual en este escenario es www. Qualcomm. copu Asumiendo que el destino final de los paquetes IP generados por la MS 110 no es la IWF 108, los paquetes son enviados a través de los protocolos de la capa de la red 224, y los protocolos de la capa de enlace 225 al siguiente encaminador (no mostrado) sobre la Internet. De esta manera, los paquetes IP de la MS 110 son comunicados a través del BS/MSC 106, y la IWF 108 hacia su destino final pretendido en la Internet, de acuerdo con el modelo de relé o relevo del estándar IS-707.5. Antes de que los paquetes de la MS 110 alcancen su destino, debe establecerse primero una conexión de enlace de datos. Como se especifica en la RFC 1661, esto requiere que cada extremo del enlace punto a punto (es decir, los protocolos PPP 206 y 226) envien primero paquetes del Protocolo de Control de Enlace (LCP) PPP para establecer, configurar y probar la conexión del enlace de datos. Después de que ha sido establecido el enlace por el LCP, el protocolo PPP 206 puede entonces enviar paquetes del Protocolo de Control de Red (NCP) para configurar los protocolos de la capa de la red 204 y 224. El NCP para el IP en los enlaces PPP es el Protocolo de Control de IP (IPCP) . El IPCP es descrito con detalle en la Petición de Comentario 1332 (RFC 1332), titulada "El PROTOCOLO DE CONTROL DEL PROTOCOLO DE INTERNET PPP (IPCP)", publicada én Mayo de 1992. Antes de la negociación del IPCP sin embargo, puede ser necesaria una fase de autentificación. Después de que cada uno de los protocolos de la capa de la red haya sido configurado, los paquetes de cada protocolo de la capa de la red pueden ser enviados sobre el enlace entre ellos .

B. Interconexión de Programas de Aplicación La mayoría, sino es que todos, los procesos que soportan la pila del protocolo de comunicación sobre la MS 110 son ejecutados por programas de aplicación. De manera general, las redes de datos convencionales emplean interconexiones de programas de aplicación (API) para permitir que los programas de aplicación funcionen en una computadora para comunicarse con programas de aplicación que funcionan en otra computadora. Las API utilizan "conectores" que protegen las aplicaciones invocantes contra diferencias en los protocolos de la red subyacente. Para lograr comunicaciones interconectadas, las API comprenden funciones, las cuales permiten a las aplicaciones, por ejemplo, abrir un conector, transmitir datos a la red, recibir datos de la red, y cerrar el conector. Las interconexiones de programación de red comunes incluyen la interconexión de conectores de Desarrollo de Sistemas Berkeley (BSD), que operan bajo un sistema operativo UnixMR, Interconexiones de Conector WindowsMR (WinSockMR) , que opera bajo un sistema operativo WindowsMR. Debido a que los conectores BSD no soportan WinSockMR, la pila de protocolo de comunicación en la MS 110 inalámbrica (véase la FIGURA 2) , es necesario un soporte API novedoso tal como una pila. En particular, lo que se necesita es un aparato y método novedosos para aplicar una estación móvil a la identificación de eventos específicos en un sistema de comunicación inalámbrico.

SUMARIO DE LA INVENCIÓN La presente invención resuelve la necesidad identificada anteriormente proporcionando un método y un aparato para una aplicación de estación móvil para identificar eventos específicos en un sistema de comunicación inalámbrico. En una implementación, la presente invención incluye una interconexión de programa de aplicación (API) que facilita comunicaciones entre una pila de protocolo de comunicación de estación móvil, que se comunica con una red de comunicación, y una aplicación de estación móvil. La API permite al menos uno de los eventos específicos sobre la base de su estado. La aplicación de estación móvil identifica entonces los eventos específicos que son permitidos.

BREVE DESCRIPCIÓN DE LOS DIBUJOS La FIGURA 1 (Técnica Anterior) es un diagrama de bloques de alto nivel de un sistema de comunicación inalámbrico en el cual una estación móvil se conecta a la Internet . La FIGURA 2 (Técnica Anterior) describe esquemáticamente las pilas de protocolo en cada entidad del Modelo de Relé TIA/EIA IS-707.5. La FIGURA 3 describe esquemáticamente las caracteristicas de una modalidad de la presente invención. Las FIGURAS 4 y 5 son diagramas de flujo para detectar un evento especifico. La FIGURA 6 es un diagrama de bloques que describe una conexión asincrónica. La FIGURA 7 es un diagrama de bloques que describe una entrada de conector asincrónico. Las FIGURAS 8-10 son diagramas de estado de modalidades de la presente invención.

DESCRIPCIÓN DETALLADA Las modalidades de la presente invención pueden ser realizadas en una variedad de implementaciones, incluyendo programas y sistemas de programación, instrucciones fijas, y/o componentes físicos de computación. En consecuencia, la operación y comportamiento de la presente invención serán descritos sin referencia especifica al código de los programas y sistemas de programación o componentes físicos de computación, deberá comprenderse que un experto en la técnica seria capaz de diseñar programas y sistemas de programación y/o componentes físicos de computación para implementar la presente invención, que permitan que una aplicación de estación móvil identifique eventos específicos, sobre la base de la descripción en ellos. La FIGURA 3 describe una aplicación 260, una pila de protocolo de comunicación 280, y una API 270 con una MS 110. La aplicación 260 y la pila del protocolo de comunicación 280 (es decir, las capas del protocolo 202, 204, 206, 208, 210, 212) se comunican a través de llamadas de función, las cuales son proporcionadas por la API 270. En otras palabras, la API 270 permite que la aplicación 260 y la pila del protocolo de comunicación 280 funcionen en diferentes procesadores y sistemas operativos sin comprometer la funcionalidad. Un experto en la técnica apreciarla que son posibles varios nombres para las funciones invocadas sin apartarse del alcance de la presente invención. Deberá notarse que la pila del protocolo de comunicación 280 contiene una pluralidad de filas de espera de envió y pilas de espera de recepción, las cuales almacenan datos. Las funciones de salida leen datos de una memoria de aplicación 260 para almacenar datos en una de las filas de espera de envió de la pila del protocolo de comunicación 280. Las funciones de entrada leen datos de una de las filas de espera de recepción de la pila del protocolo de comunicación 280 para almacenar los datos en la memoria de la aplicación 260. Para ilustrar la operación, la MS 110 recibe paquetes de IP. La pila del protocolo de comunicación 280 de la MS 110 desencapsula los paquetes de IP, y los pasa a la capa de transporte 202 (véase la FIGURA 3) . Un campo en el encabezado del paquete de IP indica el transporte, el cual puede ser TCP o UDP. Sobre la base del número de puertos de destino especificado en el encabezado de la capa de transporte, los datos son encaminados a la fila de espera de recepción apropiada de la pila del protocolo de comunicación 280, que corresponde a un conector particular. Los datos pueden entonces ser transmitidos a la aplicación 260.

En ciertas situaciones, puede ser deseable operar con paquetes que eviten las diferentes capas de la pila del protocolo 280 para reducir el efecto de latencia. Tales paquetes incluyen datos empaquetados sin tratar, tales como paquetes de IP sin tratar, los cuales carecen de información de destino (es decir, número de puerto de destino) . Por lo tanto, la aplicación de destino puede no ser determinada de los paquetes de IP sin tratar. En tales situaciones, la pila del protocolo de comunicación 280 puede transmitir los paquetes de IP sin tratar recibidos a todos los conectores registrados para soportar el protocolo de IP, por ejemplo. Esto permite que los datos cargados sean transmitidos a la aplicación de destino. Una máquina que analiza gramaticalmente un Protocolo de Mensajería de Control de Internet (ICMP), que corresponde a los paquetes de IP, puede también recibir los datos empaquetados sin tratar. La máquina analizadora gramatical ICMP bien conocida, es definida en el RFC 792, titulado "PROTOCOLO DE MENSAJES DE CONTROL DE INTERNET" . Deberá ser evidente de esta descripción que la pila del protocolo de comunicación 280, por ejemplo, procesa los paquetes recibidos antes de pasarlos de la pila a la aplicación 260, lo cual reduce la cantidad de desencapsulación a ser efectuada por la aplicación 260.

Por el contrario, la aplicación 260 puede transmitir datos empaquetados sin tratar sobre la interconexión Um, utilizando los conectores, lo cual facilita la comunicación entre la pila del protocolo de comunicación 280 y la aplicación 260. Además, la aplicación 260 puede transmitir datos empaquetados sin tratar sobre la interconexión Um. A su vez, la pila del protocolo de comunicación 280 encapsula los datos empaquetados o empaquetados sin tratar, por ejemplo, en paquetes de IP y los transmite sobre la interconexión Um. En este ejemplo, la pila del protocolo de comunicación 280 proporciona un encabezado de IP y una verificación de suma para generar los paquetes de IP. Para el ICMP, por otro lado, puede ser copiado un tipo de protocolo especifico en el encabezado del IP. Como se estableció anteriormente, la aplicación 260 puede crear un conector que permita comunicaciones de datos entre al menos una de las capas del protocolo 202, 204, 206, 208, 210, 212 y la aplicación 260 para reducir la latencia inherente al uso de la pila del protocolo de comunicación 280. Es decir, que la aplicación 260 puede crear un conector que evite la capa de transporte 202, la capa de la red 204 y la capa de enlace 206, y de este modo, permita a la aplicación 260 transmitir datos cargados a, o recibir datos cargados de la capa RLP 210.

También, la aplicación 260 puede crear un conector que permita a la aplicación 260 transmitir datos cargados a, o recibir datos cargados de, la capa IS-95 212. En una modalidad, la aplicación 260 llama una función abrir_redlib ( ) para abrir la pila del protocolo de comunicación 280 y para asignar una identificación de aplicación. La identificación de aplicación permite que aplicaciones múltiples se comuniquen con la pila del protocolo de comunicación 280 (es decir, multitarea) . Como parte de la llamada de la función abrir__redlib ( ) , por ejemplo, la aplicación 260 especifica un indicador para una función de retrodemanda de la red y una función de retrodemanda del conector. La función de retrodemanda de la red es invocada para informar a la aplicación 260 si han ocurrido (o han sido permitidos) eventos específicos del subsistema de la red, tales como leer de, escribir a, y cerrar el canal de tráfico (es decir Um) y/o una capa de enlace (es decir, PPP 206) . La función de retrodemanda del conector es invocada para informar a la aplicación 260 si han ocurrido (o han sido permitidos) eventos específicos del conector, tales como leer de, escribir a, y cerrar la capa de transporte (es decir, TCP) . Será evidente a un experto en la técnica que la red de comunicación comprende al menos uno del canal de tráfico, la capa de enlace y la capa de transporte.

Una vez que la pila del protocolo de comunicación 280 ha sido abierta, es invocada una función () vacios para iniciar una conexión del subsistema de la red, la cual incluye el canal de tráfico y la capa de enlace. Esta es una llamada amplia de aplicación, la cual no depende de un conector individual. Esta, sin embargo, requiere la identificación de la aplicación. Tras el establecimiento o falla de la conexión del subsistema de la red, es invocada la función de retrodemanda de la red para proporcionar una notificación de un evento especifico. El subsistema de la red falla, por ejemplo, sino se establece el canal de tráfico. Además, las caracteristicas del subsistema de la red pueden ser establecidas con una llamada a la función net_ioctl (). Esta llamada, por ejemplo, puede especificar la velocidad de datos de los conectores . Una vez establecida la conexión del subsistema de la red, puede ser creado un conector (o conectores) y ser inicializados a través de una llamada a la función conector (). Antes de que las funciones del conector puedan ser utilizadas, sin embargo, una llamada a la función conector () puede regresar a un descriptor del conector. Entonces, la aplicación 260 puede llamar a una función selec asinc () para registrar eventos específicos para recibir una notificación asincrónica. Este registro puede ser implementado mediante la aplicación 260 como parte de la llamada de la función, para especificar el descriptor del conector y una máscara de bit (es decir, eventos múltiples, OR'ed juntos) de los eventos específicos que requieran notificación. Si ocurre (es decir, es permitido) un evento especifico, y es detectado por la pila del protocolo de comunicación 280 o la API 270, por ejemplo, la función de retrodemanda del conectores invocada para proporcionar una notificación asincrónica. La función de retrodemanda puede notificar a la aplicación 260 de los eventos especifico mediante el uso de una señal, un mensaje incluyendo un mensaje sobre una llamada de procedimiento remoto (RPC) , o una interrupción de los componentes físicos de computación o programas y sistemas de programación. Una vez que la aplicación 260 es notificada del eventos especifico, esta puede entonces llamar a la función obtenersiguienteevento () para determinar los eventos específicos a servir. Esta función realiza una máscara de los elementos específicos que ocurrieron para el descriptor del conector especifico. También, limpia los bits en la máscara de los eventos específicos que ocurrieron. De este modo, la aplicación 260 puede no recibir notificación de los eventos específicos desactivados. La aplicación 260 debe registrar nuevamente (es decir permitir nuevamente) esos eventos específicos a través de una llamada posterior a la función selec_asinc () . Además, la aplicación 260 puede cambiar los eventos específicos registrados limpiando los bits correspondientes en la máscara de bits de eventos específicos. Si los bits ya han sido limpiados en la máscara de bits, entonces la petición es simplemente ignorada. De manera breve, la notificación del eventos puede ser desactivada sobre una base por evento, por ejemplo, a través de una llamada a la función de deselec_asinc (). Las Figuras 4 y 5 son diagramas de flujo para detectar los eventos específicos. Como se muestra en la Figura 4, por ejemplo, la pila del protocolo de comunicación 280 espera que la aplicación 260, del bloque 400, registre un evento especifico. Después de que el eventos especifico es registrado, la pila del protocolo de comunicación 280, el bloque 402, selecciona una memoria. En el bloque 404, el evento especifico puede ser detectado sobre la base de la información seleccionada en el bloque 402. En el bloque 406, es detectado el evento de escribir, por ejemplo, cuando la memoria de la pila del protocolo de comunicación 280 (es decir, la fila de espera de enviar) esta disponible para aceptar una cantidad suficiente de datos. Los datos pueden ser transmitidos desde la aplicación 260. Si la información seleccionada dei bloque 404 no es satisfactoria (es decir, que no ha ocurrido el evento especifico) , entonces la pila de protocolo de comunicación 280 continua para seleccionar la memoria, como en el bloque 402. En la Figura 5, la pila del protocolo de comunicación 280 espera que la aplicación 260 registre un evento especifico, de acuerdo a lo indicado en el bloque 500. Durante este tiempo, puede ser desactivada una notificación de interrupción. Por lo tanto, la notificación de interrupción puede no ser activada o ser activada. Después de que se registro un evento especifico, como en el bloque 500, la notificación de interrupción, en el bloque 502, puede ser activada sobre la base de la ocurrencia del evento especifico. El evento de lectura, por ejemplo, ocurre cuando están escritos datos en la memoria de la pila de comunicación 280 (es decir, la fila de espera de recepción) . De este modo, el bloque 504, es detectado el evento de lectura por la pila del protocolo de comunicación 280 cuando recibe la notificación de interrupción, que fue activada debido a la ocurrencia del evento. Los datos almacenados en la memoria de la pila del protocolo de comunicación 280 pueden ser de la red de comunicación. Además, para el evento de lectura, los datos almacenados pueden ser transmitidos a la aplicación 260. Finalmente, el evento de cierre detectado cuando está disponible un conector para su reutilizacion debido a que, por ejemplo, una conexión de enlace de datos, tal como la capa de transporte, es terminada. Los siguientes ejemplo de conexión asincrónica (véase la Figura 6) y una entrada asincrónica (véase la Figura 7) son proporcionados para iniciar el uso de la notificación de un evento asincrónico. Refiriéndose a la Figura 6, tanto la pila del protocolo de comunicación 280 es introducida y las funciones de retrodemanda son especificadas a través de una llamada a la función abrir_redlib (). La llamada a la función abrir ppp () (A) inicia la conexión del subsistema de la red (B) . Después de que la conexión del subsistema de la red ha sido establecida, es invocada la función de retrodemanda (C) para reportar la disponibilidad del subsistema de la red. Asumiéndose que ha sido abierto y asignado un conector, una llamada a la función conectar () (D) inicia una conexión TCP(E). Además, la aplicación 260 llama a la función selec_asinc () (F) para registrar los eventos específicos para recibir la notificación. En este ejemplo, el evento especifico de interés es el evento de escritura, el cual ocurre tras establecer una conexión. Tras establecer la conexión, es invocada la función de retrodemanda si el evento especifico esta registrado en la máscara. Si es asi, entonces es invocada la función de retrodemanda (G) para proporcionar una notificación asincrónica. Una vez que la aplicación 260 es notificada, esta llamada a la función obtenersiguienteeventos () (H) para determinar que evento especifico ocurrió (I) . También, esta llamada limpia los bits del evento (es decir, el evento de escritura) en la máscara (J) . La aplicación 260 debe registra nuevamente la notificación posterior del evento especifico a través de la llamada a la función selec_asinc (). En la Figura 7, se proporciona una ilustración de una lectura del conector asincrónico. Para iniciar la lectura, la aplicación 260 hace una llamada a la función de leer () (A). Asumiendo una ausencia de datos que leer, la aplicación 260 llamada a la función selec_asinc () (B) para registrar un evento (es decir, fijar el bit correspondiente en la máscara) para recibir la notificación. En este ejemplo, el eventos especifico de interés es el evento de lectura, el cual ocurre cuando existen datos que leer por la aplicación 260. espera de recepción, es invocada la función de retrodemanda si es especificado el evento de lectura en la máscara. Si es asi, entonces es invocada la función de retrodemanda (C) para proporcionar una notificación asincrónica. Una vez notificada la aplicación 260, esta llamada a la función obtener siguiente evento () (D) para determinar cual evento ocurrió (E) . También, esta llamada limpia los bits de evento en la máscara (F). La aplicación 260 debe permitir nuevamente la notificación posterior del evento a través de la llamada a la función selec_asinc ( ) . Finalmente, para leer los datos almacenados en la fila de espera de recepción, la aplicación 260 hace la llamada a la función de leer() (G) . En las FIGURAS 8-10 son ilustradas máquinas de estado de las modalidades de la presente invención. En las FIGURAS 8-9, se asumió que la pila del protocolo de comunicación 280 está abierta, y la conexión del subsistema de la red (es decir, canal de tráfico, y la capa de enlace si es necesario - los conectores sin tratar pueden evitar los subsistemas de la red) se estableció. Un experto en la técnica apreciarla que son posibles varios nombres para los estados sin apartarse del alcance de la presente invención.

La máquina de estado, la cual puede transitar asincrónicamente entre estados, controla (es decir, activa y desactiva) los eventos específicos, tales. como lectura, escritura y cierre. Los eventos específicos pueden ser desactivados al inicio de la operación y pueden ser activados en estados predeterminados para ayudar a la aplicación 260 para identificar el estado de la MS 110. También, la API 270 reporta mensajes de estado específicos que son particulares (es decir, no meramente genéricos) a la aplicación 260 sobre la base del estado de la API 270 y el tipo de función llamada por la aplicación 260. Los mensajes de estado específicos, pueden reflejar el estado de la red de comunicación subyacente. Los mensajes de estado son reportados a la aplicación 260 como argumentos de las llamadas de función, por ejemplo. En la FIGURA 8, por ejemplo, se ilustra un diagrama de estado para un conector TCP de la API 270. El conector inicializado comienza en el estado "nulo" 800. El conector no "existe" debido a que no ha sido asignado aún. El conector puede ser creado e inicializado a través de una llamada a la función de conector (), la cual regresa el descriptor del conector a utilizarse con las funciones relacionadas con el conector. Después de la llamada a la función de conector () , la máquina de estado transita a un estado de "inicialización" 805. En el estado de inicialización 805, la máquina de estado transita nuevamente al estado nulo 800 cuando es terminada la posibilidad de una conexión TCP por una llamada a la función cerrar (). La llamada a la función cerrar () libera todos los recursos relacionados con el conector. Por otro lado, una llamada a la función conectar () inicia la conexión TCP y las transiciones de la máquina de estado a un estado de "abertura" 810. En el estado de abertura 810, la máquina de estado transita a un estado "cerrado" 815 cuando; (1) ocurre una falla del subsistema de la red, (2) una falla en el establecimiento de la conexión TCP, o (3) un cambio de dirección de IP. También, después de una llamada a la función cerrar (), la cual termina la conexión TCP, la máquina de estado hace transitar al conector a un estado de "cierre" 820, mientras son iniciados los procedimientos de terminación. Finalmente, la máquina de estado transita a un estado "abierto" 825 tras ser establecida la conexión TCP. En el estado abierto 825, el conector se abre para leer y escribir. En particular, el evento de escritura es permitido inmediatamente, mientras que el evento de lectura es permitido sobre la base de si están almacenados datos en la memoria de la pila del protocolo de comunicación 280. La máquina de estado transita al estado cerrado 815 si: (1) ocurre una falla del subsistema de la red; (2) falla el establecimiento de la conexión TCP; (3) un intento por terminar la conexión TCP, tal como un reajuste de TCP, un TCP abortado, o un TCP cerrado iniciado por un servidor de la red; y (4) el cambio de la dirección de IP. Una terminación de conexión TCP iniciada por la aplicación, tal como por una llamada a la función cerrar (), hace transitar la máquina de estado al estado de cierre 820. En el estado cerrado 815, los eventos de lectura, escritura y cerrar son todos impuestos. Después de una llamada a la función de cerrar (), la cual termina la conexión TCP, la máquina de estado hace transitar el conector al estado nulo 800, que libera el conector y se vuelve disponible para reutilizarse. En el estado de cierre 820, la máquina de estado transita a un estado "esperar para cerrar" 830 si: (1) ocurre una falla del subsistema de la red; (2) el intento por terminar la conexión TCP, tal como el reajuste de TCP, o el TCP cerrado iniciado por el servidor de la red; (3) una expiración de un temporizador y (4) el cambio de la dirección de IP. Para la protección contra el retraso en la terminación de la conexión TCP, la API 270 implementa el temporizador, el cual es activado tras el inicio de la terminación de la conexión del TCP. Como se observa, la expiración del temporizador, hace transitar la máquina de estado al estado de esperar para cerrar 830. En el estado de esperar para cerrar 830, una llamada a la función de cerrar () termina la conexión TCP y hace transitar la máquina de estado a un estado nulo 00. El evento de cerrar es impuesto en este estado 830. Las Tablas 1-3 ilustran mensajes de estado específicos soportados por la API 270. En el estado nulo (no mostrado en las Tablas 1-3), un mensaje de estado especifico, el cual es descriptivo, de que "no existen recursos adicionales disponibles" puede ser reportado a la aplicación 260.

Tabla 1 Tabla 1 (Continuación) Estado Mensaje de Estado Especifico para un tipo de Función de Conexión Cerrar No existe conexión de TCP debido a la ausencia del intento de origen, o falló el intento de conexión Esperar para No existe conexión de TCP debido a la Cerrar ausencia del intento de origen, o falló el intento de conexión; o Error de red genérico; la red subyacente no está disponible Cerrado Error de red genérico; la red subyacente no está disponible; El intento de conexión fue rechazado debido a un reajuste del servidor; Retraso de la conexión en progreso; o La dirección del IP a nivel de la red cambio, lo cual hizo que la conexión del TCP se reajustara, debido a una resincronización de PPP.

Tabla 2 Estado Mensaje de Estado Especifico para un tipo de Función 1/0 Inicializar No existe conexión de TCPO debido a la ausencia de intento de origen, o el intento de conexión fallo Abrir Si está fuera una llamada de la función de bloqueo, la operación se bloquearla Abierto Si está fuera una llamada de la función de bloqueo, la operación se bloquearla (número de bytes de lectura/escritura) Cerrar La conexión de TCP no existe debido a la ausencia de intento de origen, o el intento de conexión fallo Esperar para La conexión de TCP no existe debido a la Cerrar ausencia de intento de origen, o el intento de conexión fallo; o Error de red genérico; la red subyacente no está disponible Cerrado Error de red genérico; la red subyacente no está disponible; El servidor reajustó la conexión; recepción de un reajuste del servidor; La conexión TCP se abortó debido a un retraso u otra razón; o Tabla 2 (Continuación) Tabla 3 A manera de ejemplo, la Figura 9 ilustra un diagrama de estado para un conector UDP del API 270. El conector inicializado comienza en un estado "nulo" 900. Como se hizo notar anteriormente con respecto al estado nulo 800, el conector no "existe" debido a que no ha sido asignado. El conector puede ser creado e inicializado a través de una llamada a la función del conector (), el cual regresa el escritor del conector a utilizarse con las funciones relacionadas con el conector. Después de la llamada a la función de conector (), la máquina de estado transita a un estado "abierto" 905. En el estado abierto 905, el conector es abierto para leer y escribir. En articular, el evento de escritura es permitido inmediatamente, mientras que el evento de lectura es permitido sobre la base de si están almacenados los datos en la memoria de la pila del protocolo de comunicación 280. La máquina de estado transita a un estado "cerrado" 910 cuando ocurren fallas en el subsistema de la red. Una terminación de conexión UDP iniciada por la aplicación, tal como por una llamada a la función de cerrar (), transita la máquina de estado al estado nulo 900. En el estado cerrado 910, los eventos de lectura, escritura y cierre son todos permitidos. Después de una llamada a la función de cerrar (), la cual termina la conexión UDP, la máquina de estado hace transitar al conector al estado nulo 900, el cual libera el conector y lo vuelve disponible para ser reutilizado.

Las Tablas 4-6 ilustran mensajes de estado específicos soportados por la API 270. En el estado nulo (no mostrado en las Tablas 4-6), el mensaje de estado especifico de que "no existen recursos adicionales disponibles" como se estableció anteriormente, puede ser reportado a la aplicación 260.

Tabla 4 Tabla 5 Tabla 6 Estado Mensajes de estado específicos para un tipo de función de cierre Abierto Exito-sin condición de error reportada Cerrado Exito-sin condición de error reportada La Figura 10 ilustra un diagrama de estado para controlar los subsistemas de la red, como el canal de tráfico (es decir, Um) y la capa de enlace (es decir, PPP 206). Una llamada a la función abrir_redlib () abre el subsistema de la red, e inicializa un conector en un estado "cerrado" 1000. Una llamada a la función de abrir PPP () inicia la conexión del subsistema de la red, la cual hace transitar el conector a un estado de "abertura" 1005. También, una página a la MS 110 por una llamada PPP entrante hace transitar el conector al estado de abertura 1005. En ambos casos, tras la negociación exitosa, la MS 110 intenta sincronizar y establecer el RLP y PPP a través del canal de tráfico. En el estado de abertura 1005, el conector transita a un estado "abierto" 1010 para ser establecida la conexión del subsistema de la red. Por otro lado, el conector transita nuevamente al estado cerrado 1000 si no se establece la conexión del subsistema de la red.

En el estado abierto 1010, es invocada la función de retrodemanda para identificar eventos específicos por la aplicación 60, tales como lectura, escritura y cierre, que son permitidos. En este momento, la MS 110 puede comunicarse a través del canal de tráfico. El conector, sin embargo, transita al estado cerrado 1000 cuando ocurren fallas del subsistema de la red, lo cual invoca a la función de retrodemanda. Una terminación de la conexión del subsistema de la red iniciada por la aplicación, tal como una llamada a la función de cerrar (), hace transitar al conector a un estado de "cierre" 1015. En el estado de cierre 1015, el conector transita al estado cerrado 1000 cuando la conexión del sistema de la red es terminada. En el estado cerrado 1000, la función de retrodemanda es invocada para identificar los eventos especificados 260 por la aplicación que son permitidos. La Tabla 7 ilustra mensajes de estado específicos que corresponden a llamadas de función particulares, y que son soportadas por la API 270.

Tabla 7 Llamada de Mensajes de estado específicos función (y descripción) conector ( ) Dirección no soportada; crea un Identificador de Aplicación no Válido; conector y El protocolo es de tipo erróneo para el regresa un conector; descriptor de Parámetro de conector no válido o no conector soportado; Protocolo no soportado; o No más recursos de conector disponibles conectar () Si esta fuera una llamada de la función de inicia bloqueo, la operación seria bloqueada; conexión TCP Descriptor conector no válido; El intento de conexión fue rechazado debido a la recepción de un reajuste del servidor; Retraso de conexión; La memoria intermedia de la aplicación no forma parte del espacio de dirección válido; Tamaño no válido especificado para la longitud de dirección o longitud de mensaje; Tabla 7 (Continuación) Llamada de Mensajes de estado específicos función (y descripción) La dirección IP a nivel de la red cambio, le cual hizo que la conexión TCP se reajustara, debido a una resincronizacion del PPP; Conexión en progreso; Descriptor de conector ya conectado; Error de red genérico; La red subyacente no está disponible; Dirección de servidor especificada no valida; Dirección ya en uso; o Dirección de destino requerida Abrir PPP () Si esta fuera una llamada de la función de establece una bloqueo, la operación se bloquearla; conexión de Identificador de aplicación especificado no red válido; o Terminación de la conexión de la red en progreso red_ioctl () Identificador de aplicación especificado no fija las válido; caracteristicas Petición o parámetro no válido; de la red Conexión de red establecida; o Conexión de red en progreso; Tabla 7 (Continuación) Llamada de Mensajes de estado específicos función (y descripción) abrir_redlib () No más aplicaciones disponibles- se excedió abre la pila el número máximo de aplicaciones abiertas del protocolo de comunicación cerrar-redlib () Identificador de aplicación especificado no cierra la pila válido; del protocolo Existen conectores asignados; o de comunicación La conexión de la red está aún establecida unir () Descriptor de conector especificado no para conectores válido; cliente, une una Operación especificada no válida o no dirección local soportada; y el valor de un Dirección ya en use-puerto al Operación no válida; o conector Parámetros de dirección especificados no válidos cerrar ( ) Descriptor de conector especificado no cierra un conector válido; o para liberar este Si esta fuera una llamada en la función de para ser bloqueo, la operación seria bloqueada reutilizado Tabla 7 (Continuación) Llamada de Mensajes de estado específicos función ;y descripción; cerrar PPP () Si esta fuera una llamada a la función de bloqueo, la operación seria bloqueada; cierra la Identificador de aplicación especificado no conexión de la válido; o red Terminación de la conexión de la red en progreso estadodelared () Identificador de aplicación especificado no reporta el válido; estado de la La red subyacente no está disponible; conexión de la Conexión de red establecida y disponible; red Conexión de red en progrese- Terminación de la conexión de la red en progrese- Servicio no CDMA (es decir, canal de tráfico) disponible; Servicio CDMA disponible, pero falló el origen debido a que la estación base no soporta la opción de servicio; o Servicio CDMA disponible, pero el origen falló, sin embargo, no debido a que la estación base no soporte la opción de servicio Tabla 7 (Continuación) Llamada de Mensajes de estado específicos función (y descripción) selec ansie () Descriptor de conector especificado no registra eventos válido específicos para particular Obtenersiguiente Descriptor de conector especificado no evento () válido; o obtiene el Identificador de aplicación especificado no siguiente valido descriptor del conector y eventos que han ocurrido escribir () Descriptor de conector especificado no escribe un valido; número No existe conexión TCP; especifico de El servidor reajusto la conexión TCP; bytes-memorias Se abortó la conexión TCP debido a un intermedias retraso u otra falla; Tabla 7 (Continuación) Llamada de Mensajes de estado específicos función (y descripción) contiguas o no La dirección IP al nivel de al red cambió, contiguas lo cual hizo que la conexión TCP se reajustara, debido a una asincronización del PPP; Conexión TCP cerrada; Red no disponible; Memoria intermedia de aplicación no valida como parte del espacio de dirección; o Sin memorias intermedias libres disponibles para la escritura leer () Descriptor de conector especificado no lee un número valido; especifico de No existe conexión TCP; bytes-memorias El servidor reajusto la conexión TCP; intermedias Se abortó la conexión TCP debido a un contiguas o no retraso u otra falla; contiguas La dirección IP al nivel de al red cambió, lo cual hizo que la conexión TCP se reajustara, debido a una asincronización del PPP; Conexión TCP cerrada; _L Tabla 7 (Continuación) Llamada de Mensajes de estado específicos función (y descripción) Red no disponible; Memoria intermedia de aplicación no valida como parte del espacio de dirección; Sin memorias intermedias libres disponibles para la lectura Final del marcador de archivo recibido enviara () Descriptor de conectores especificados no enviar un válidos; número Familia de dirección no reportada; especifico de Sin memorias intermedias libres disponibles bites para la escritura; Red no disponible; Memoria intermedia de aplicación no valida como parte del espacio de dirección; Opción especificada no soportada. recvde ( ) Descriptor de conectores especificados no lee un número validos; especifico de Familia de dirección no reportada; bites Sin memorias intermedias libres disponibles para la escritura; Red no disponible; Tabla 7 (Continuación) Llamada de función .y Mensajes de estado específicos descripción) Memoria intermedia de aplicación no valida como parte del espacio de En otra modalidad, la máquina de estado puede leer un medio legible por una máquina que comprenda información codificada, como un código de programa y sistemas de programación codificados, para hacer que el proceso descrito anteriormente permita que una aplicación de estación móvil identifique eventos específicos. El medio legible por una máquina puede aceptar la información codificada de un dispositivo de almacenamiento, tal como una memoria o un disco de almacenamiento, o de la red de comunicación. También, el medio legible por una máquina puede ser programado con la información codificada cuando el medio sea manufacturado. La máquina puede comprender al menos una de la aplicación 260, la pila del protocolo de comunicación 280, y la API 270, mientras que el medio legible por una máquina puede comprender una memoria o disco de almacenamiento. Aunque esta invención ha sido mostrada en relación a modalidades particulares, no deberá considerarse limitada. Más bien, la invención es limitada solo por el alcance de las reivindicaciones anexas y sus equivalente. Se hace constar que con relación a esta fecha, el mejor método conocido por la solicitante para llevar a la práctica la citada invención, es el que resulta claro de la presente descripción de la invención.

Claims (28)

REIVINDICACIONES Habiéndose descrito la invención como antecede, se reclama como propiedad lo contenido en las siguientes reivindicaciones.

1. Un método para una aplicación de estación móvil para identificar una pluralidad de eventos específicos, el método se caracteriza porque comprende: comunicación entre una pila del protocolo de comunicación de estación móvil y una red de comunicación; comunicación entre la pila del protocolo de comunicación de estación móvil y la aplicación de la estación móvil a través de una interconexión de aplicación de estación móvil; permitir, por medio de la interconexión de la aplicación de la estación móvil, al menos uno de los eventos específicos sobre la base del estado de la interconexión de aplicación de la estación móvil; e identificar, por medio de la aplicación de la estación móvil, los eventos específicos que son permitidos .

2. El método de conformidad con la reivindicación 1, caracterizado porque la aplicación de la estación móvil identifica los eventos especificados que son permitidos llamando una función.

3. El método de conformidad con la reivindicación 1, caracterizado porque la interconexión de la aplicación de la estación móvil comprende una pluralidad de estados.

4. El método de conformidad con la reivindicación 3, caracterizado porque interconexión de la aplicación de la estación móvil transita de manera asincrónica entre los estados.

5. El método de conformidad con la reivindicación 1, caracterizado porque la pluralidad de eventos específicos incluyen al menos uno de los eventos de lectura, escritura y cierre.

6. El método de conformidad con la reivindicación 1, caracterizado porque comprende la interconexión de la aplicación de la estación móvil que desactiva al menos uno de los eventos específicos sobre la base del estado de la interconexión de la aplicación de la estación móvil.

7. El método de conformidad con la reivindicación 5, caracterizado porque el evento de escritura es permitido cuando se establece una conexión de la red de comunicación.

8. El método de conformidad con la reivindicación 5, caracterizado porque el evento de lectura es permitido cuando se establece una conexión de la red de comunicación, y están almacenados los datos en una memoria de la pila del protocolo de comunicación de la estación móvil.

9. El método de conformidad con la reivindicación 5, caracterizado porque los eventos de lectura, escritura y cierre son permitidos cuando ocurre una falla de la red de comunicación.

10. El método de conformidad con la reivindicación 5, caracterizado porque los eventos de lectura, escritura y cierre son permitidos cuando, existe una falla para establecer una conexión de la red de comunicación, un intento por terminar la conexión de la red de comunicación, o un cambio de una dirección de identificación de la red.

11. El método de conformidad con la reivindicación 10, caracterizado porque la dirección de identificación de la red incluye una dirección de IP.

12. El método de conformidad con la reivindicación 5, caracterizado porque el evento de cierre es permitido cuando, ocurre una falla de la red de comunicación, un intento por terminar una conexión de la red de comunicación, una expiración de un temporizador, o un cambio de una dirección de identificación de la red.

13. El método de conformidad con la reivindicación 12, caracterizado porque la dirección de identificación de la red incluye una dirección de IP.

14. El método de conformidad con la reivindicación 12, caracterizado porque el temporizador es activado tras el inicio para terminar la conexión de la red de comunicación.

15. El método de conformidad con la reivindicación 5, caracterizado porque el evento de escritura es permitido cuando es asignado un conector.

16. El método de conformidad con la reivindicación 5, caracterizado porque el evento de lectura es permitido cuando es asignado un conector, y están almacenados datos en una memoria de la pila del protocolo de comunicación de la estación móvil.

17. Un aparato para una aplicación de estación móvil para identificar una pluralidad de eventos específicos, el aparato se caracteriza porque comprende: una pila del protocolo de comunicación de estación móvil para comunicarse con una red de comunicación; una interconexión de aplicación de estación móvil para permitir al menos uno de los eventos específicos sobre la base del estado de la interconexión de aplicación de la estación móvil; y una aplicación de estación móvil para identificar los eventos específicos a ser permitidos, donde la interconexión de la aplicación de la estación móvil está adaptada para facilitar comunicaciones entre la aplicación de la estación móvil y la pila del protocolo de comunicación de la estación móvil .

18. El aparato de conformidad con la reivindicación 17, caracterizado porque la aplicación de la estación móvil está adaptada para identificar los eventos específicos a ser permitidos por una llamada de función.

19. El aparato de conformidad con la reivindicación 17, caracterizado porque la interconexión de la aplicación de la estación móvil comprende una pluralidad de estados.

20. El aparato de conformidad con la reivindicación 19, caracterizado porque la interconexión de la aplicación de la estación móvil está adaptada para la transición asincrónica entre los estados.

21. El aparato de conformidad con la reivindicación 17, caracterizado porque los eventos especificados incluyen al menos uno de los eventos de lectura, escritura y cierre.

22. El aparato de conformidad con la reivindicación 17, caracterizado porque la interconexión de la aplicación de la estación móvil está adaptada para desactivar al menos uno de los eventos especificados sobre la base del estado de la interconexión de la aplicación de la estación móvil.

23. Un medio legible por una máquina, caracterizado porque comprende información codificada, la cual cuando es leida por una máquina, produce el proceso de: comunicación entre una pila del protocolo de comunicación de la estación móvil y una red de comunicación; comunicación entre la pila del protocolo de comunicación de la estación móvil y una aplicación de estación móvil a través de una interconexión de aplicación de la estación móvil; permitir, por medio de la interconexión de la estación móvil, al menos uno de los eventos especificados sobre el estado de la interconexión de la aplicación de la estación móvil; e identificación, por la aplicación de la estación móvil de los eventos específicos que son permitidos.

24. El medio legible por una máquina de conformidad con la reivindicación 23, caracterizado porque la aplicación de la estación móvil identifica los eventos específicos que son permitidos por una llamada de una función.

25. El medio legible por una máquina de conformidad con la reivindicación 23, caracterizado porque la interconexión de la aplicación de la estación móvil comprende una pluralidad de estados.

26. El medio legible por una máquina de conformidad con la reivindicación 25, caracterizado porque la interconexión de la aplicación de la estación móvil transita de manera asincrónica entre los estados.

27. El medio legible por una máquina de conformidad con la reivindicación 23, caracterizado porque la pluralidad de eventos específicos incluyen al menos uno de los eventos de lectura, escritura y cierre.

28. El medio legible por una máquina de conformidad con la reivindicación 23, caracterizado porque comprende además la interconexión de la aplicación de la estación móvil que desactiva al menos uno de los eventos específicos sobre la base del estado de la interconexión de la aplicación de la estación móvil.