MXPA02009521A - Metodo y aparato para una aplicacion de estacion movil para recibir y transmitir datos empaquetados sin procesar. - Google Patents

Abstract

La presente invencion se relaciona con un aparato y un metodo para una aplicacion de estacion movil para recibir y transmitir datos empaquetados sin procesar en un sistema de comunicacion inalambrico. La presente invencion una aplicacion de estacion movil que crea al menos un interruptor. Al menos una de las capas del protocolo de estacion movil recibe datos empaquetados sin procesar encapsulados de una red de comunicacion. Los datos empaquetados sin procesar carecen de informacion del puerto de destino. Al menos una de las capas del protocolo de estacion movil transmite datos empaquetados sin procesar no encapsulados a los interruptores creados. A su vez, los interruptores creados transmiten los datos empaquetados sin procesar a la aplicacion de la estacion movil. En otra implementacion, los interruptores creados datos empaquetados sin procesar de la aplicacion de estacion movil a al menos una de las capas de protocolo de la estacion movil. A su vez, al menos una de las capas del protocolo de la estacion movil transmite datos empaquetados sin procesar encapsulados a la red de comunicacion.

Description

MÉTODO Y APARATO PARA UNA APLICACIÓN DE ESTACIÓN MÓVIL PARA RECIBIR Y TRANSMITIR DATOS EMPAQUETADOS SIN PROCESAR.

ANTECEDENTE DE LA INVENCIÓN Campo de la invención Esta invención se refiere generalmente al campo de las comunicaciones inalámbricas. Particularmente más, la presente invención se refiere a un método novedoso y un aparato para una aplicación de estación móvil para recibir y transmitir datos empaquetados sin procesar en un sistema de comunicaciones inalámbrico.

Descripción del arte relacionado A. La comunicación inalámbrica Las innovaciones recientes en las comunicaciones inalámbricas y en las tecnologías relacionadas con los ordenadores, así como el crecimiento sin precedentes de suscriptores de Internet, han pavimentado el camino para la computación móvil. De hecho, la popularidad de la computación móvil ha establecido demandas mayores en la infraestructura actual del Internet para proveer más apoyo a los usuarios móviles. El sustento de esta infraestructura es el Protocolo de Internet (IP) encaminado al empaquetamiento, el cual provee varios servicios, incluyendo el direccionamiento y el encaminamiento de paquetes (datagramas) entre redes locales y de cobertura amplia (LANs Y ANs) . El protocolo IP está definido en la Solicitud de Comentario (RFC por sus siglas en inglés) titulada "PROTOCOLO DARPA DE INTERNET, ESPECIFICACIÓN DE PROTOCOLO DE PROGRAMA DE INTERNET", con fecha septiembre de 1981. El protocolo IP es un protocolo en capas de red que encapsula los datos dentro de paquetes IP para su transmisión. El encaminamiento y el direccionamiento de información se añaden al encabezado del paquete. Los encabezados IP, por ejemplo, contienen direcciones de 32 bits que identifican los servidores receptores y emisores. Esas direcciones las usan intermediarios de ruta para seleccionar una ruta para los paquetes a través de la red hacia su último destino en la dirección deseada. De ese modo, el protocolo IP permite a los paquetes que se originan en cualquier nodo de Internet en el mundo encaminarse hacia cualquier otro nodo de Internet en el mundo. Por otro lado, una capa de transporte, la cual comprende ya sea un Protocolo de Control de Transmisión (TCP) o a un Protocolo de Usuario de Diagramas de Datos (UDP) , se usa para dirigirse a aplicaciones particulares.

La tendencia actual es para que los usuarios móviles usen computadoras móviles, como las laptop o las palmtop, junto con dispositivos de comunicación inalámbricos, como teléfonos celulares o teléfonos portátiles, para tener acceso a Internet. Es decir, al igual que los usuarios convencionalmente emplean dispositivos de comunicación por "cableado" para conectar sus computadoras a redes con base terrestre, los usuarios móviles utilizarán dispositivos de comunicación inalámbricos, a los que comúnmente se hace referencia como "estaciones móviles" (MSs) , para conectar sus terminales móviles a dichas redes. El uso en la presente de la estación móvil o MS se referirá a cualquier estación suscriptora en la red de radio inalámbrico pública. La Fig. 1 (arte previo) ilustra un diagrama de alto nivel en bloque de un sistema de comunicación de datos inalámbrico, en el cual el MS 110 se comunica con una Función de Interconexión (I F) 108, vía un Centro Conmutador Móvil/Estación Base (BS/MSC) 106. La IFW 108 sirve como el punto de acceso a Internet. La I F 108 se acopla a, y a menudo se ubica junto a la BS/MSC 106, la cual puede ser una estación base inalámbrica convencional, como se conoce en el arte. Otro protocolo estándar que se dirige al sistema de comunicación de datos inalámbrico es el Proyecto 2 de la Asociación de la 3a Generación ("3rdGPP2") titulado "IP DE LA RED ESTÁNDAR INALÁMBRICA", publicado en diciembre de 1999. Por ejemplo, el IP de la 3G de la Red Estándar Inalámbrica incluye un Nodo Servidor de Datos en Paquete ("PDSN", por sus siglas en inglés), el cual funciona como la IWF 108. Hay varios protocolos que dirigen las comunicaciones de datos entre la MS 110 y la I F 108, por ejemplo, el de la Asociación de Industrias de las Telecomunicaciones (TÍA) /Asociación de Industrias de la Electrónica (EIA) Estándar Provisional (IS-95 por sus siglas en inglés) , titulado "ESTÁNDAR DE COMPATIBILIDAD DE ESTACIÓN DE UNA ESTACION/BASE MÓVIL PARA UN SISTEMA CELULAR DE ESPECTRO DIFUNDIDO E? BANDA ANCHA DE MODO DUAL", publicado en julio de 1993, provee generalmente sistemas de comunicación inalámbricos para espectro difundido en banda ancha. Aún más, el estándar TIA/EIA IS707.5, titulado "OPCIONES DE SERVICIO DE DATOS PARA SISTEMAS DE ESPECTRO DIFUNDIDOS EN BANDA ANCHA: SERVICIOS DE DATOS EN PAQUETE", publicado en febrero de 1998, define los requerimientos para el respaldo de la capacidad de transmisión de datos en paquete en los sistemas TIA/EIA IS-95 y especifica los servicios del portador de datos en paquete que se pueden usar para la comunicación entre la MS 110 y la I F 108 vía el BS/MSC 106. También el estándar TIA/EIA IS-707-A.5, titulado "OPCIONES DE SERVICIOS DE DATOS PARA SISTEMAS DE ESPECTRO DIFUNDIDOS: SERVICIOS DE DATOS EN PAQUETE", y el estándar TIA-EIA IS-95 titulado "OPCIONES DE SERVICIO DE DATOS PARA SISTEMAS DE ESPECTRO DIFUNDIDOS: SERVICIOS DE DATOS EN PAQUETE DE ALTA VELOCIDAD", ambos publicados en marzo de 1999, también definen requerimientos para el soporte de transmisión de datos en paquete en los sistemas TIA-EIA IS-95. Además, otro protocolo estándar que dirige las comunicaciones entre la MS y la I F 108 es el TIA/EIA IS-2000, titulado "INTRODUCCIÓN LOS ESTÁNDARES CDMA 2000 PARA SISTEMAS DE ESPECTRO DIFUNDIDO" , publicado en julio de 1999. El IS-707.5 introduce modelos de opción de protocolo de comunicación entre la MS 110 y la BS/MSC 106 (la interfase Um) , y entre la BS/MSC 106 y la IWF 108 (la interfase L) . Por ejemplo, un Modelo Transmisor representa la situación en la que un vínculo de Protocolo Punto a Punto (PPP, por sus siglas en inglés) existe en la interfase Um entre la MS 110 y la IWF 108 (la interfase L) . El protocolo PPP se describe con detalle en la Solicitud de Comentarios 1661 (RFC 1661) , titulada "EL PROTOCOLO DE PUNTO A PUNTO (PPP)". La Fig. 2 (arte previo) es un diagrama de las pilas de protocolos en cada entidad del Modelo Transmisor IS- 707.5. En el extremo izquierdo de la figura está una pila de protocolo de comunicación, mostrada en un formato vertical convencional, mostrando las capas de protocolo corriendo en la MS 110. La pila de protocolo MS 110 se ilustra conforme se conecta lógicamente a la pila del protocolo BS/MSC 106 durante la interfase Um. La pila de protocolo BS/MSC 106 está, a su vez, ilustrada conforme se conecta lógicamente a la pila de protocolo I F 108 durante la interfase L. La operación representada en la Fig. 2 es la siguiente: una entidad de protocolo de capa superior 200, tal como una aplicación de programa corriendo en la MS 110 tiene la necesidad de enviar datos mientras está en Internet. Una aplicación representativa puede ser un programa de navegador de web (por ejemplo, Netscape Navigator™, Microsoft Internet Explorer™) . El navegador de web le solicita al Localizador de Recurso Universal (URL, por sus siglas en inglés) , semejante al HIPERVÍNCULO http : //www. Qualcomm. com/ . Un protocolo Sistema de Nombre de Dominio (DNS) , también un protocolo de capa superior 200, traduce el nombre textual del servidor www. Qualcomm. com a una dirección IP numérica de 32 bits por el uso de una resolución de nombre de dominio, la cual traduce los nombres a direcciones en el Internet. El Protocolo de Traslado de Hipertexto (HTTP), el cual es también un protocolo de capa superior 200, construye un mensaje GET para la URL solicitada, y especifica que el TPC se usará para enviar el mensaje y para operaciones HTTP. La capa de transporte 202 usa un puerto 80, el cual se conoce en el arte como el puerto destinatario para encaminar las operaciones HTTP a la aplicación. El protocolo TCP, el cual es un protocolo de capa de transporte 202, abre una conexión para la dirección IP especificada por el DNS y transmite el mensaje GET a nivel de aplicación HTTP. El protocolo TCP especifica que el protocolo IP se usará para el transporte de mensaje. El protocolo IP, el cual es un protocolo de capa en la red 204, transmite los paquetes TCP a la dirección IP especificada. El PPP, que es un protocolo de capa de enlace 206, codifica los paquetes IP y los transmite al protocolo de capa de transmisión 208. Un ejemplo del protocolo de capa de transmisión 208 puede ser el estándar TIA/EIA ilustrado el cual se define en "INTERFASE ENTRE EL EQUIPO TERMINAL DE DATOS Y EL EQUIPO TERMINAL DEL CIRCUITO DE DATOS QUE EMPLEA EL INTERCAMBIO DE DATOS BINARIOS SERIALES", publicado en octubre de 1997. Se debe entender que otros estándares o protocolos, conocidos por los artesanos de habilidad ordinaria en el arte, se pueden usar para definir la transmisión a través de las capas. Por ejemplo, otros estándares aplicables pueden incluir a la "ESPECIFICACIÓN DE BUS (USB) SERIAL UNIVERSAL, Revisión de edición 1.1", publicado en septiembre de 1998, y la "NÚCLEO DE ESPECIFICACIÓN BLUETOOTH VERSIÓN 1. OA" , publicado en julio de 1999. Por último, el protocolo de capa de transmisión 208 pasa los paquetes PPP a un Protocolo de Enlace de Radio (RLP) 210 y luego al protocolo IS-95 212 para su transmisión al BS/MSC 106 durante la interfase Um. El protocolo RLP 210 se define en el estándar IS-707.2, titulado "OPCIONES DE SERVICIO DE DATOS PARA SISTEMAS DE ESPECTRO DIFUNDIDOS EN BANDA ANCHA: PROTOCOLO DE ENLACE DE RADIO", publicado en febrero de 1998, y el protocolo IS-95 se define en el estándar IS-95 arriba indefinido. Un protocolo de capa de transmisión complementario 220 en la BS/MSC 106 recibe los paquetes PPP durante la interfase Um a través de la capa IS-95 218 y luego a una capa RLP 216. El protocolo de capa transmisora 220 los pasa durante la interfase L a un protocolo de capa transmisora 228 en la I F 108. Una capa de enlace 226 de protocolo PPP en la I F 108 recibe los paquetes PPP desde el protocolo de capa repetidor 228, y termina la conexión entre la MS 110 y la I F 108. Los paquetes se pasan de la capa PPP 226 a la capa IP 224 en la IWF 108 para la examinación del encabezamiento de paquete IP para su encaminamiento final, el cual en este escenario es ww . Qualcomm. com. Suponiendo que el destino final de los paquetes IP generados por la MS 110 no es la I F 108, los paquetes se remiten a través de los protocolos de capa en la red 224 y protocolos de capa de enlace 225 hacia el siguiente encaminador (no visible) en el Internet. De esta manera, los paquetes PPP de la MS 110 son comunicados a través de la BS/MSC 106 y la IWF hacia su último destino determinado en el Internet en concordancia con el modelo repetidor estándar IS-707.5. Antes de que los paquetes MS 110 lleguen a su destino, la conexión de enlace de datos se debe establecer primero. Como se especificó en la RFC 1661, se requiere que cada extremo del enlace punto a punto (es decir, los protocolos PPP 206 y 226) envíe primero los paquetes PPP del Protocolo de Control de Enlace (LCP, por sus siglas en inglés) para establecer, configurar y probar la conexión de enlace de datos . Después de que se estableció el enlace por el LPC, el protocolo PPP 206 puede entonces enviar los paquetes de Protocolo de Control en la Red (NCP) para configurar los protocolos de capa en la red 204 y 224. El NCP para IP en los enlaces PPP es el Protocolo de Control IP (IPCP por sus siglas en inglés) . El IPCP se describe con detalle en la Solicitud de Comentario 1332 (RFC 1332) , titulada "EL PROTOCOLO DE CONTROL DE DEL PROTOCOLO DE INTERNET PPP (IPCP)", publicado en mayo de 1992. Sin embargo, antes de la negociación del IPCP, puede ser necesaria una fase de autenticación. Después de que cada una de los protocolos de capa en la red se ha configurado, los paquetes de cada protocolo de capa en la red se puede enviar durante el enlace entre ellos.

B. Inferíase del Programa de Aplicación La mayoría, si no es que todos de los procesos que apoyan las pilas de protocolos de comunicación en la MS 110 se ejecutan por medio de los programas de la aplicación. Generalmente, las redes de datos convencionales emplean interfaces de programas de aplicación (APIs) para posibilitar que corran los programas de aplicación en una computadora para que se comuniquen con los programas de aplicación que corren en otra computadora. Los APIs utilizan "interruptores" los cuales alojan las aplicaciones que se invocan de las diferencias en los protocolos de la red subyacente para alcanzar las comunicaciones distribuidas en Internet, los APIs comprenden funciones, las cuales permiten a las aplicaciones, por ejemplo, abrir un interruptor, transmitir datos a la red, recibir datos desde la red y cerrar el interruptor. Las interfaces de programación en la red comunes incluyen intefases de interruptores del Desarrollo de Sistemas Berkeley (BSD) , el cual opera bajo un sistema operativo Unix ™, y la interfase de interruptores Windows ™ (WinSock™) el cual opera bajo un sistema operativo Windows™. Debido a que ni los interruptores BSD ni los WinSock™ apoyan la pila de protocolo de comunicación en las MS inalámbricas (ver FIG. 2) una novedad que respalda el API que respalda dicha pila es necesaria. En particular, lo que se necesita es un método novedoso y un aparato para una aplicación de estación móvil para recibir y transmitir datos empaquetados sin procesar en una sistema de comunicación inalámbrico.

SUMARIO DE LA INVENCIÓN La presente invención se dirige a la necesidad arriba identificada al proveer un método y un aparato para una aplicación de estación móvil para recibir y transmitir datos empaquetados sin procesar en un sistema de comunicación inalámbrico. En una implementaron, una aplicación de estación móvil crea al menos un interruptor. Al menos una de las capas del protocolo de la estación móvil transmite datos empaquetados sin procesar no encapsulados a al menos un interruptor. A su vez, al menos un interruptor transmite los datos empaquetados sin procesar a la aplicación de la estación móvil. En otra implementaron, al menos un interruptor transmite datos empaquetados sin procesar de la aplicación de la estación móvil al menos una de las capas del protocolo de estación móvil. A su vez, a menos una de las capas del protocolo de estación móvil transmite datos empaquetados sin procesar a la red de comunicación.

BREVE DESCRIPCIÓN DE LOS DIBUJOS Fig.l (Arte previo) es un diagrama en bloque de alto nivel de un sistema de comunicación inalámbrico en el cual una estación móvil se conecta al Internet. Fig.2 (Arte previo) describe esquemáticamente las pilas de protocolo en cada entidad del modelo de retransmisión TIA/EIA IS-707.5. Fig.3 representa esquemáticamente elementos de una modalidad de la presente invención. Figs.4 y 5 son listas de flujo para detectar un evento especifico. Fig.6 es un diagrama en bloque que representa una conexión asincrona. Fig.7 es un diagrama en bloque que representa una entrada de interruptor asincrono.

Figs.8-10 son diagramas de estado de las modalidades de la presente invención.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN Las modalidades de la presente invención se pueden realizar en una variedad de implementaciones, incluyendo software, firmware y/o hardware. A partir de ahí, la operación y el comportamiento de la presente invención se describirá sin referencia especifica al código de software o los componentes de hardware, se entiende que una persona de habilidad ordinaria en el arte estaría en posibilidad de diseñar software y/o hardware para implementar la presente invención, la cual posibilita a una aplicación de estación móvil recibir y transmitir datos empaquetados sin procesar, basados en la descripción que aquí se hace. La Fig. 3 representa una aplicación (260) , una pila (280) , de protocolo de comunicación, y una API (270) , dentro de un MS (110) . La aplicación (260) y la pila (280) del protocolo de comunicación (por ejemplo, las capas de protocolo 202,204,206,208,210,212) se comunican a través de llamadas de función, las cuales son provistas por la API (270) . En otras palabras, API (270) permite a la aplicación (260) y a la pila (280) del protocolo de comunicación correr en diferentes procesadores y sistemas operativos sin comprometer la funcionalidad. Una persona hábil apreciaría que varios nombres para las funciones invocadas son posibles sin alejarse del alcance de la presente invención. Debiera notarse que la pila (280) del protocolo de comunicación contiene una pluralidad de filas de espera para recibir y filas de espera para enviar, las cuales son datos almacenados. Las funciones de salida leen datos desde una memoria de la aplicación (260) para almacenar los datos dentro de una de las filas de la pila (280) del protocolo de comunicación. Las funciones de entrada leen datos desde una de las filas receptoras de la pila (280) del protocolo de comunicación para almacenar los datos dentro de la memoria de la aplicación (260) . Para ilustrar la operación, la MS (110) recibe paquetes IP. La pila (280) del protocolo de comunicación de la MS (110) desencapsula los paquetes IP, y los pasa a la capa (202) de transporte (ver fig. 3) . Un campo en el encabezamiento del paquete IP indica el transporte, el cual puede ser ya sea un TCP o un UDP. Basado en e numero del puerto de destino especificado en el encabezamiento de la capa de transporte, los datos se encaminan hacia la fila receptora apropiada de la pila (280) del protocolo de comunicación, el cual corresponde a un interruptor particular. Los datos pueden entonces transmitirse a la aplicación (260) . En ciertas situaciones, puede ser deseable operar con paquetes que desvíen varias capas de la pila (280) de protocolo para reducir efectos de retraso. Dichos paquetes incluyen datos empaquetados sin procesar, tales como los paquetes IP, los cuales carecen de información de destino (p.ej. numero de puerto destino) . De ese modo, la aplicación de destino puede no estar determinada desde los paquetes IP sin procesar. En tales situaciones, la pila (280) del protocolo de comunicación puede transmitir los paquetes IP sin procesar recibidos a todos los interruptores registrados para apoyar al protocolo IP, por ejemplo. Esto permite a los datos de carga útil transmitirse a la aplicación destino. Un motor de análisis, Protocolo de Control de Mensaje en Internet (ICMP, por sus siglas en ingles) el cual responde a los paquetes IP, puede también recibir los datos empaquetados sin procesar. El bien conocido motor de análisis ICMP se define en la RFC (792) , titulado "PROTOCOLO DE CONTROL DE MENSAJE DE INTERNET" . Debiera ser claro desde esta descripción que la pila (280) del protocolo de comunicación, por ejemplo, procese los paquetes recibidos antes de pasarlos hasta la aplicación (260) de la pila, lo cual reduce la cantidad de desencapsulación que tiene que hacer la aplicación (260) . A la inversa, la aplicación (260) puede transmitir datos empaquetados sin procesar durante la interfase Um, al usar los interruptores lo cual facilita las comunicaciones entre la pila (280) del protocolo de comunicación y la aplicación (260) . Además, la aplicación puede transmitir datos empaquetados sin procesar durante la interfase Um. A su vez, la pila (280) del protocolo de comunicación encapsula los datos empaquetados sin procesar o los datos empaquetados, por ejemplo, la pila (280) del protocolo de comunicación provee un encabezamiento IP a un suma total para generar los paquetes IP. Por otro lado, para el ICMP, un tipo de protocolo especificado se puede copiar dentro del encabezamiento IP. Como se estableció arriba la aplicación (260) puede crear un interruptor que permita las comunicaciones de datos entre al menos una de las capas de protocolo 202.204.206.208.210.212 y la aplicación 260 para reducir el retraso inherente al uso de la pila (280) de protocolo de comunicación. Es decir, la aplicación (260) puede crear un interruptor que desvía la capa (202) de transporte, la capa (204) de red, y la capa (206) de vinculo y de ese modo, permite a la aplicación (260) transmitir datos de carga útil para la capa (210) RLP o recibir datos de carga útil desde la misma. También, la aplicación (260) puede crear un interruptor que permite a al aplicación (260) transmitir datos de carga útil a la capa (212) IS-95 o recibir datos de carga útil de la misma. En una modalidad, la aplicación (260) llama una función open_netlib () para abrir la pila (280) del protocolo de comunicación y para asignar una identificación de aplicación. La identificación de aplicación permite a múltiples aplicaciones de comunicarse con la pila (280) del protocolo de comunicación (p.ej., multitareas) . Como parte del llamado a la función open_netlib () , por ejemplo, la aplicación (260) especifica un indicador a una función de llamada de respuesta de la red y a una función de llamada de respuesta de interruptor. La función de respuesta de llamado de la red se invoca para informar a la aplicación (260) siempre que eventos específicos de subsistema de red, tales como leer desde, escribir para, y cerrar el canal de tráfico (p.ej., Um) y/o una capa de vinculo (p.ej., PPP 206), han ocurrido (o han estado posibilitados) . La función de respuesta de llamado del interruptor se invoca para informar a la aplicación (260) siempre que eventos especificados del interruptor, tales como leer desde, escribir para y cerrar la capa de transporte (p.ej., TCP), han ocurrido (o han estado posibilitado. Debiera ser claro para quien es hábil en el arte que una red de comunicación comprende al menos unos de los canales de trafico, la capa-enlace, y a la capa de transporte. Una vez que la pila (280) del protocolo de comunicación se abre, una función pppopen () se llama para iniciar la conexión del subsistema de red, la cual incluye el canal de trafico y la capa-enlace. Esta es una llamada de aplicación amplia, la cual no depende de un interruptor individual. Sin embargo, requiere la identificación de aplicación, durante el establecimiento o la falla de la conexión del subsistema de red, la función de llamada de respuesta de la red se invoca para proveer una notificación de evento especifica. Por ejemplo, el subsistema de la red falla si el canal de tráfico no esta establecido. Además, las características del subsistema de red pueden establecerse con una llamada a la función net_ioctl(). Esta llamada, por ejemplo, puede especificar la proporción de datos de los interruptores . Una vez que la conexión del subsistema de red se estableció, un interruptor (o interruptores) se puede crear he iniciar a través de una llamada a la función interruptor () . Sin embargo, antes de que se pueda usar las funciones de interruptor la llamada a la función interruptor () puede regresar a un descriptor de interruptor. Después, la aplicación (260) puede llamar una función async_select () para registrar eventos específicos para recibir notificación asincrona. El registro se puede implementar por medio de la aplicación (260) , como parte de la función de llamada, para especificar al descriptor interruptor y a un bit mascara (p.ej., eventos múltiples OR'ed) de los eventos especificados que requieren notificación. Si un evento especifico ocurre (p.ej., esta posibilitado), y es detectado por la pila (280) del protocolo de comunicación o API (270) , por ejemplo, la función de respuesta de llamada del interruptor se invoca para proveer notificación asincrona. La función de respuesta de llamada puede notificar a la aplicación (260) sobre el evento especifico por el uso de una señal, un mensaje, incluyendo un mensaje durante la llamada de proceder remota (RPC), o una interrupción de hardware o software.

Una vez que la aplicación (260) es notificada del evento específico, puede entonces llamar la función genextevent () para determinar los eventos específicos para darles servicio. Esta función regresa una máscara de los eventos específicos que ocurren para el descriptor de interruptor especificado. También limpia los bits en la máscara de los eventos específicos que ocurren. De ese modo, la aplicación (260) no puede recibir más la notificación de los eventos especificados inhabilitados. La aplicación (260) debe volver a registrar esos eventos específicos (p.ej., rehabilitar) a través de una llamada subsecuente a la función async_select () . Además, la aplicación (260) puede cambiar los eventos específicos registrados al limpiar los bits correspondientes en la mascara de bit de los eventos específicos. Si los bits ya están limpios en la mascara de bit, entonces la solicitud simplemente se ignora. En resumen, la notificación de evento se puede deshabilitar en una base pre-evento, por ejemplo, a través de una llamada a la función async_deselct () . Las figs. 4 y 5 son listas de flujo para detectar los eventos específicos. Como se mostró en la fig. 4, por ejemplo la pila (280) de protocolo de comunicación espera por la aplicación (260) , en bloque (400) para registrar un evento especifico. Después de que el evento especifico se registra, la pila (280) del protocolo de comunicación, en bloque (402), interroga una memoria. En el bloque (404) , el evento especifico se puede detectar basado en la información encuestada del bloque (402) . En el bloque (406) , el evento de escribir se detecta, por ejemplo, cuando la memoria de la pila (280) del protocolo de comunicación esta disponible para aceptar una cantidad suficiente de datos (por ejemplo, la fila de enviar) . Los datos se pueden transmitir desde la aplicación (260) , si la información encuestada del bloque (404) no es satisfactoria (p.ej., el evento no ha ocurrido), entonces la pila (280) del protocolo de comunicación continua hacia encuestar la memoria, como en el bloque (402) . En la fig.5, la pila (280) del protocolo de comunicación espera que la aplicación registre un evento especifico, como el indicado en el bloque (500) . Durante este tiempo, un aviso de interrupción se puede deshabilitar. Como tal, el aviso de interrupción no puede poner en movimiento o ser puesto en movimiento. Después de que el evento específico se registra, como en el bloque (500) , el aviso de interrupción, en el bloque (502) , se pude poner en movimiento basado en que suceda el evento especifico. El evento leer, por ejemplo, ocurre cuando los datos se escriben en la memoria de la pila (280) del protocolo de comunicación (p.ej. la fila recibir) . De ese modo, en el bloque (504) , el evento leer se detecta por la pila (280) del protocolo de comunicación cuando recibe el aviso interrumpir, el cual fue puesto en movimiento debido a que sucede el evento. Los datos almacenados en la memoria de la pila (280) del protocolo de comunicación pueden ser de la red de comunicación. Además, del evento leer, los datos almacenados se pueden transmitir a al aplicación (260) . Por ultimo, el evento cerrar se detecta cuando un interruptor esta disponible para volverse a usar por que, por ejemplo, una conexión de vinculo de datos, como la capa de transporte se termino. Los siguientes ejemplo de conexión asincrona (ver fig.6) y una entrada asincrona (ver fig. 7) se proveen para ilustrar el uso de notificación de evento asincrono.

En referencia a la fig.6, tanto la pila (280) de protocolo de comunicación como las funciones de respuesta de llamada son entradas como específicos a través de la llamada a la función open_netlib () . La llamada a la función pppopen () (A) inicia la conexión del subsistema de red (B) . Después de que la conexión del subsistema de red se ha establecido, la función de la llamada de respuesta se invoca (C) para reportar la disponibilidad del subsistema de red. Suponiendo que un interruptor ha sido abierto y localizado una llamada para funcionar connect () (D) inicia una conexión TCP (E) . Además, la aplicación (260) llama la función async_select () (F) para registrar los eventos específicos para recibir la notificación. En este ejemplo el evento especifico de interés es el evento escribir, el cual ocurre al establecer una conexión. Al establecer la conexión, la función respuesta de llamada es invocada si el evento especifico se registra en la mascara. Si es así, entonces la función de respuesta de llamada se invoca (G) para proveer la notificación asincrona. Una vez que la aplicación (260) se notifica, llama la función getnextevent () (H) para determinar cual evento especifico ocurrió. También, esta llamada limpia el bit del evento (p.ej., el evento escribir) en la mascara (J) . La aplicación (260) debe volver a registrar la notificación subsecuente del evento especifico a través de la llamada a la función async_select () . En la fig.7, una ilustración de un interruptor asincrono de leer se provee. Para iniciar el leer, la aplicación (260) hace una llamada a al función leer () (A) suponiendo una carencia de datos por leer, la aplicación (260) llama la función async_select () (B) para registrar un evento (p.ej., establecer el bit correspondiente en la mascara) para recibir notificación. En este ejemplo, el evento especifico de interés es el evento leer, el cual ocurre cuando ahí datos para leer por la aplicación (260) .

Durante el almacenaje de datos en la fila recibir, la función respuesta de llamada se invoca si el evento leer esta especificado en la mascara. Si es así entonces la función respuesta de llamada se invoca (C) para proveer la notificación asincrona. Una vez que la aplicación (260) se notifica, llama la función getnextevent () (D) para determinar que evento ocurrió (E) . También, esta llamada limpia el bit del evento en la mascara (F) . La aplicación (260) desde rehabilitar la notificación subsecuente del evento a través de la llamada a ala función async_select () . Por ultimo, para leer los datos almacenados en la fila recibir, la aplicación (260) hace la llamada a la función leer () (G) . En las fig.8-10, se ilustran las maquinas de estado de las modalidades de la presente invención. En las fig.8-9, se supone que la pila (280) del protocolo de comunicación esta abierta y la conexión del subsistema de red se establece (p.ej., el canal de trafico, y la capa de vinculo - si es necesario - los interruptores sin procesar pueden desviar al subsistema de red) . Alguien hábil en el arte apreciaría que son posibles varios nombres para los estados, sin alejarse del alcance de la presente invención.

La maquina de estado, la cual puede asincrónicamente transitar entre estados, (p.ej., habilita y deshabilita) controla los eventos específicos, tales como leer, escribir y cerrar. Los eventos específicos pueden deshabilitarse al inicio de la operación y se pueden habilitar en estados predeterminados para asistir a la aplicación (206) para identificar el estado de la MS (110) . También, API (270) reporta mensajes de condición especifica que son particulares para la aplicación (260) (p.ej., no solo genéricos) basados en el estado de API (270) y en el tipo de función llamada por la aplicación (260) . Los mensajes de condición especifica pueden reflejar el estado de la red de comunicación subyacente. Los mensajes de condición se reportan a la aplicación (260) como argumentos de llamadas de función, por ejemplo. En la fig.8, se ilustra por ejemplo, un diagrama de estado para un interruptor de TCP de un API (270) . El interruptor no iniciado comienza el estado (800) "invalidación" . el interruptor no "existe" por que no ha sido localizado, hasta ahora. El interruptor se puede crear e iniciar a través de una llamada interruptor () , la cual regresa el interruptor descriptor para usar las funciones relacionadas con el interruptor. Después de la llamada a la función interruptor () , la maquina de estado transita a un estado (805) "iniciar". En el estado (805) iniciar, la maquina de estado transita de regreso al estado (800) invalido siempre que la posibilidad de una conexión TCP se termine por una llamada a la función cerrar (). La llamada a la función cerrar () libera todos los recursos relacionados con interruptor. Por otro lado, una llamada a la función connect () inicia la conexión TCP y transita la maquina de estado a un estado (810) "abierto". En el estado (810) abierto, la maquina de estado transita al estado (815) cerrado siempre que: (1) ocurre una falla del subsistema de red, (2) una falla para establecer la conexión TCP o (3) una dirección IP cambio. También, después de una llamada a la función cerrar () , el cual terminan la conexión TCP, la maquina de estado transita al interruptor hacia un estado (820) "cerrando" mientras que los procedimientos de terminación se inician. Por ultimo, la maquina de estado transita hacia un estado (825) "abierto" mientras la conexión TCP esta siendo establecido. En el estado (825) abierto, el interruptor se abre para leer y escribir. En particular, el evento escribir se habilita inmediatamente, mientras el evento leer se habilita basado en que si los datos se almacenan en la memoria de la pila (280) del protocolo de comunicación. La maquina de estado transita al estado (815) cerrado siempre que: ' (1) ocurre una falla en el subsistema de red, (2) la falla para establecer la conexión TCP, (3) un intento para terminar la conexión TCP, como el un receto de TCP, un aborto de TCP, o un TCP iniciado que lo cierra un servidor de la red, y (4) el cambio de la dirección IP. Una aplicación de terminación de conexión TCP iniciada, como la de una llamada de la función cerrar () , transita la maquina de estado hacia el estado (820) cerrando . En el estado (815) cerrado, los eventos leer, escribir y cerrar están todos impuestos. Después de una llamada a la función cerrar () , la cual termina la conexión TCP, la maquina de estado transita el interruptor al estado (800) invalido, lo cual libera a interruptor y lo hace disponible para volver a usarlo. En el estado (820) cerrando, la maquina de estado transita hacia el estado (830) "espere para cerrar" siempre y cuando: (1) ocurra una falla en el subsistema de la red, (2) el intento determinar la conexión TCP como el reincido de la TCP, o que el inicio de TCP sea cerrado por el servidor en la red, (3) el tiempo haya expirado y (4) el cambio de dirección de IP. Para protección contra el retraso al terminar la conexión TCP, el API (270) implementa el temporizador, el cual se activa durante el inicio de la terminación de conexión de TCP. Como se ha visto la expiración del temporizador transita la maquina de estado al estado (830) de esperar para cerrar. En el estado (830) de esperar para cerrar una llamada a la función close () termina la conexión TCP y I transita la maquina de estado al estado (800) invalido.

El evento cerrar se impone a este estado (830) . Las tablas 1-3 ilustran los mensajes de condición especifica apoyados por API (270) . En el estado invalido (no visible en las tablas 1-3) , un mensaje de condición especifica, el cual es descriptivo de que "no hay recursos adicionales disponibles" se puede reportar a la aplicación (260) .

Tabla 1 Tabla 2 Estado Mensajes de condición especifican para un tipo de función 1/0 Iniciar La conexión TCP no existe debido a una carencia de intento origen o falló el intento de conexión Abriendo Si esta fuera una llamada de la función bloquear, la operación se bloquearía Abierto Si esta fuera una llamada a la función bloquear, la operación se bloquearía (número de bytes leído/escrito) Cerrando La conexión TCP no existe debido a una carencia de intento de origen o el intento de conexión falló Esperar La conexión TCP no existe debido a una carencia de para intento de origen o el intento de conexión falló; o cerrar 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 reinició la conexión, recepción de un reinicio del servidor; conexión TCP abortada debido a un receso u otra razón; o la conexión TCP no existe debido a una carencia de intento de origen o el intento de conexión falló Tabla 3 Estado Mensajes de condición especifican para un a función del tipo Cerrar Iniciar Éxito -no hay error de condición reportado Abriendo Si esta fuera una llamada de la función bloquear, la operación se bloquearía Abierto Si esta fuera una llamada a la función bloquear, la operación se bloquearía Cerrando Si esta fuera una llamada ala función bloquear, la operación se bloquearía Esperar Éxito -no hay error de condición reportado para cerrar Cerrado Éxito -no hay error de condición reportado A manera de ejemplo, la Fig. 9 ilustra el diagrama de estado para un interruptor UDP o API (270) . El interruptor sin iniciar comienza en un estado (900) "inválido" . Como se hizo notar arriba con respecto al estado (800) inválido, el interruptor no "existe" porque no ha sido localizado. El interruptor se puede crear e iniciar a través de una llamada a la función socket 0 , el cual regresa el descriptor de interruptor al uso con funciones relacionadas con el interruptor. Después de la llamada a la función socket () , la máquina de estado transita a un estado (905) "abierto". En el estado (905) abierto, el interruptor se abre para leer o escribir. En particular, el evento escribir se habilita inmediatamente, mientras que el evento leer se habilita basado en que si los datos están almacenados en la memoria de la pila (280) del protocolo de comunicación. La máquina de estado transita hacia un estado (910) "cerrado" siempre y cuando ocurra la falla del subsistema de red. Una aplicación UPD iniciada en la terminación conexión, como la de una llamada a la función close (), transita la máquina de estado al estado (900) inválido. En el estado (910) cerrar, los eventos leer, escribir y cerrar están todos habilitados. Después de la llamada a la función close () , la cual termina la conexión UPD, la máquina de estado transita el interruptor al estado (900) inválido, el cual libera el interruptor y lo deja disponible para volver a usarlo. Las tablas 4-6 ilustran mensajes de condición específica respaldados por API (270) . En el estado inválido (no visible en las tablas 4-6) , el mensaje de condición específica "no hay recursos adicionales disponibles", como se manifestó arriba, se pueden reportar a la aplicación (260) .

Tabla 4 La Fig. 10 ilustra un diagrama de estado para controlar el subsistema de red, como el canal de trafico (p.ej., Um) y la capa-enlace (p.ej., PPP (206)). Una llamada para la función open_netlib () abre el subsistema de red e inicializa un interruptor hacia un estado (1000) "cerrado". Una llamada a la función pppopen () inicia la conexión del subsistema de red, la cual transita el interruptor a un estado (1005) "abriendo". También, una página de la MS (110) a través de una llamada entrante transita el interruptor a un estado (1005) abriendo. En ambos casos, en una negociación exitosa, la MS (110) intenta sincronizar y establecer tanto el RLP como la PPP a través del canal de tráfico. En el estado (1005) abriendo, el interruptor transita hacia un estado (1010) "abierto" mientras se establece la conexión del subsistema de red. Por otro lado, el interruptor transita de regreso el estado (1000) cerrar si la conexión del subsistema de red no se estableció. En el estado (1010) abierto, se invoca la función de respuesta de llamada para identificar la aplicación (1060) de eventos específicos, tales como leer, escribir y cerrar que se habilitan. Para este momento, la MS (110) se puede comunicar a través de canal de trafico. Sin embargo, el interruptor transita al estado (100) cerrado siempre que ocurra una falla en el subsistema de red, el cual invoca la función de respuesta de llamada una aplicación iniciada en la terminación de conexión del subsistema de la red, como el de llamara a la función close () , transita al interruptor a un estado (1015) "cerrando" . En el estado (1015) cerrando, e interruptor transita al estado (1000) siempre que se termine la conexión del subsistema de la red. En el estado (1000) cerrado, la función de respuesta de llamada se invoca para identificar la aplicación (260) de eventos específicos que están habilitados. La tabla 7 ilustra mensajes de condición especificas que corresponden a llamadas de función particulares, y que están respaldadas por API (270) .

Tabla 7 Connect () Si esta fuera una llamada de función de Inicia la conexión bloqueo, la operación se bloquearía; TCP Descriptor de interruptor invalido; Intento de conexión fue denegado debido a la recepción de un reinicio de servidor; Conexión en receso; Aplicación de memoria intermedia que no es parte del espacio de dirección valido; tamaño invalido especificado para la longitud de dirección o longitud de mensaje; Nivel de dirección IP de la red cambiado, lo cual causo el reinicio de la conexión TCP, debido a una resincroniación; Conexión en progreso; Descriptor de interruptor ya conectado; Error de red genérico; la red subyacente no esta disponible; Dirección especificada de servidor invalida; Dirección ya en uso; o Destino requerido de dirección. pppopen ( ) Si esta fuera una llamada de función de establece la bloqueo la operación se bloquearía; conexión de red Identificador de aplicación especifico invalido; o Conexión de la red en progreso. open_netlib () No mas aplicaciones disponibles -Abre la pila del máximo numero de aplicaciones excedido. protocolo de comunicación. close_netlib (] Identificador de aplicación especifico Cierra pila de invalido; protocolo de Hay interruptores ubicados existentes; comunicaron o La conexión de la red esta aun establecida. bind () Descriptor del interruptor especifico para interruptores invalido; clientes adjuntos a Operación especifica invalida o no direcciones locales respaldada; y valor de puerto Dirección aun en uso; para el interruptor Operación invalida; o Parámetro de dirección especifico invalido. write () Descriptor de interruptor específico inválido; escribe un número Conexión TCP no existente; de bytes específico El servidor reinicia la conexión TCP; -memorias Conexión TCP abortada debido a receso u intermedias otra falla; contiguas o no Nivel de dirección IP en la red contiguas cambiado, el cual causó el reinicio de la conexión TCP, debido a un resincronización PPP; Conexión TCP cerrada; Red no disponible; Parte no válida de memoria intermedia de aplicación de espacio de dirección; o Ninguna memoria intermedia disponible para escribir read () Descriptor de interruptor específico inválido; leer un número Conexión TCP no existente; específico de bytes El servidor reinicia la conexión TCP; -memorias Conexión TCP abortada debido a un temporales receso u otra falla; contiguas o no Nivel de dirección IP en la red contiguas cambiado, lo cual causó el reinicio de la conexión TCP, debido a una resincronización PPP; Conexión TCP cerrada; Red no disponible; Parte no valida de la memoria temporal de la aplicación del espacio de dirección; No hay memorias temporales disponibles para lectura; o Fin de marcador de archivo recibido sendto () Descriptor de interruptor específico inválido; envía un número Familia de dirección no respaldada; específico de bytes No hay memorias temporales disponibles para escribir; Red no disponible; Parte de espacio de dirección no válida de la memoria temporal de la aplicación; Opción específica no respaldada; o Dirección destino solicitada recvfrom () Descriptor de interruptor específico inválido; lee un número Familia de dirección no respaldada; específico de bytes No hay memorias temporales disponibles para escribir; Red no disponible; Parte de espacio de dirección no válida de la memoria temporal de la aplicación; Opción específica no respaldada; En otra modalidad, una máquina puede leer un medio legible a máquina que comprende información codificada, como un código de software codificado, para causar el proceso arribe descrito que posibilita a la aplicación de una estación móvil recibir y transmitir datos empaquetas sin procesar. El medio legible en máquina puede aceptar la información codificada desde un dispositivo de almacenaje, como una memoria o un disco de almacenaje o desde la red de comunicación. También el medio legible en máquina se puede programar con la información codificada cuando se fabrica este medio. La máquina puede comprender al menos una aplicación (260) , una pila (280) del protocolo de comunicación y una API (270) , mientras que el medio legible en máquina puede comprender una memoria o un disco de almacenaje. Aunque esta invención se ha mostrado en relación con las modalidades particulares, no debiera considerarse tan limitada. En vez de ello, la invención está limitada sólo por el alcance de las reivindicaciones anexas y sus equivalentes .

Claims (27)

NOVEDAD DE LA INVENCIÓN Habiendo descrito la presente invención, se considera como novedad y, por lo tanto, se reclama como propiedad lo anterior en las siguientes: REIVINDICACIONES

1. Un método para una aplicación de estación móvil para recibir datos empaquetados sin procesar, el método comprende : crear, por medio de una aplicación de estación móvil, al menos un interruptor; recibir, por medio de al menos una pluralidad de capas de protocolos de estación móvil, datos empaquetados sin procesar encapsulados desde una red de comunicación, los datos empaquetados sin procesar que carecen de información del puerto destino; transmitir, por medio de al menos una de las capas de protocolo de la estación móvil, datos empaquetas sin procesar no encapsulados hacia al menos un interruptor; y transmitir, por medio de al menos un interruptor, los datos empaquetados sin procesar a la aplicación de estación móvil.

2. El método de la reivindicación 1, que además comprende transmitir los datos empaquetados sin procesar a una máquina de análisis de un Protocolo de Control de Mensajes por Internet.

3. El método de la reivindicación 1, caracterizado porque los datos empaquetados sin procesar incluyen paquetes IP sin procesar.

4. El método de la reivindicación 1, caracterizado porque la pluralidad de capas de protocolo de la estación móvil incluye, al menos, una capa de protocolo de vínculo de radio de estación móvil y una capa de protocolo IS-95 de estación móvil.

5. El método de la reivindicación 1, caracterizado porque la pluralidad de capas de protocolo incluye una pila de protocolo de comunicación de estación móvil.

6. Un aparato para una aplicación de estación móvil para recibir datos empaquetados sin procesar, el aparato comprende : una aplicación de estación móvil para crear al menos un interruptor; y una pluralidad de capas de protocolo de estación móvil, en donde al menos una capa de protocolo de estación móvil se adapta para recibir datos empaquetados sin procesar desde una red de comunicación, los datos empaquetados sin procesar carecen de información de puerto destino; en donde al menos una capa de protocolo de estación móvil se adapta para transmitir datos empaquetados sin procesar no encapsulados a al menos un interruptor; y en donde al menos un interruptor se adapta para transmitir los datos empaquetados sin procesar a la aplicación de la estación móvil.

7. El aparato de la reivindicación 6, caracterizado porque al menos un interruptor se adapta para transmitir los datos empaquetados sin procesar a una máquina de análisis de un Protocolo de Control de Mensajes en Internet.

8. El aparato de la reivindicación 6, caracterizado porque los datos empaquetados sin procesar incluyen paquetes IP sin procesar.

9. El aparato de la reivindicación 6, caracterizado porque la pluralidad de capas de protocolo de estación móvil incluye al menos una capa de protocolo de vínculo de radio de estación móvil y una capa de protocolo IS-95 de estación móvil.

10. El aparato de la reivindicación 6, caracterizado porque la pluralidad de capas de protocolo incluye una pila de protocolo de comunicación de estación móvil .

11. Un medio legible en máquina que comprende información codificada, la cual cuando una máquina la lee causa el proceso siguiente: crear, por medio de una aplicación de estación móvil, al menos un interruptor; recibir, por medio de al menos una pluralidad de capas de protocolo de estación móvil, datos empaquetados sin procesar encapsulados desde una red de comunicación, los datos empaquetados sin procesar carecen de información de puerto destino; transmitir, por medio de al menos una de las capas de protocolo de estación móvil, datos empaquetados sin procesar no encapsulados hacia al menos un interruptor; y transmitir, por medio de al menos un interruptor, los datos empaquetados sin procesar a la aplicación de estación móvil.

12. El medio legible en máquina de la reivindicación 11, que además comprende transmitir los datos empaquetados sin procesar a un motor de análisis de un Protocolo de Control de Mensajes en Internet.

13. El medio legible en máquina de la reivindicación 11, caracterizado porque los datos empaquetados sin procesar incluyen paquetes IP sin procesar.

14. El medio legible en máquina de la reivindicación 11, caracterizado porque la pluralidad de capas de protocolo de la estación móvil incluye al menos una capa de protocolo de vínculo en radio de una estación móvil y una capa de protocolo IS-95 de estación móvil.

15. El medio legible en máquina de la reivindicación 11, caracterizado porque la pluralidad de capas de protocolo de la estación móvil incluye una pila de protocolo de comunicación de la estación móvil.

16. Un método para una aplicación de estación móvil para transmitir datos empaquetados sin procesar, el método comprende : crear, por medio de una aplicación de estación móvil, al menos un interruptor; transmitir, por medio de al menos un interruptor, datos empaquetados sin procesar de la aplicación de estación móvil a al menos una pluralidad de capas de protocolo de estación móvil; y transmitir, por medio de al menos una pluralidad de capas de protocolo de estación móvil, datos empaquetados sin procesar encapsulados a una red de comunicación.

17. El método de la reivindicación 16, caracterizado porque los datos empaquetados sin procesar incluyen paquetes IP de datos sin procesar.

18. El método de la reivindicación 16, caracterizado porque la pluralidad de capas de protocolo de estación incluye, al menos, una capa de protocolo de vínculo en radio de estación móvil y una capa de protocolo IS-95 de estación móvil.

19. El método de la reivindicación 16, caracterizado porque la pluralidad de capas de protocolo de estación móvil incluye una pila de protocolo de comunicación de estación móvil.

20. Un aparato para una aplicación de estación móvil para transmitir datos empaquetados sin procesar, el aparato comprende : una aplicación de estación móvil para crear al menos al menos un interruptor; y una pluralidad de capas de protocolo de estación móvil, caracterizada porque al menos un interruptor se adapta para transmitir datos empaquetados sin procesar de la aplicación de estación móvil a al menos una de las capas del protocolo de estación móvil; y caracterizado porque al menos una de las capas del protocolo de estación móvil se adapta para transmitir datos empaquetados sin procesar encapsulados a una red de comunicación.

21. El aparato de la reivindicación 20, caracterizado porque los datos empaquetados sin procesar incluyen paquetes IP sin procesar. •

22. El aparato de la reivindicación 20, caracterizado porque la pluralidad de capas del protocolo de estación móvil incluye, al menos, una capa de protocolo de vínculo en radio de estación móvil y una capa de protocolo IS-95 de estación móvil.

23. El aparato de la reivindicación 20, caracterizado porque la pluralidad de capas de protocolo de estación móvil incluye una pila de protocolo de comunicación de estación móvil.

24. Un medio legible en máquina que comprende información codificada, el cual cuando lo lee una máquina causa lo siguiente: crear, por medio de una aplicación de estación móvil, al menos un interruptor; transmitir, por medio de al menos un interruptor, datos empaquetados sin procesar de la aplicación de la estación móvil a al menos una pluralidad de capas de protocolo de estación móvil; y transmitir, por medio de al menos una pluralidad de capas de protocolo de estación móvil, datos empaquetados sin procesar encapsulados a una red de comunicación.

25. El medio legible en máquina de la reivindicación 24, caracterizado porque los datos empaquetados sin procesar incluyen paquetes IP sin procesar.

26. El medio legible en máquina de la reivindicación 24, caracterizado porque la pluralidad de capas de protocolo de estación móvil incluye, al menos, una capa de protocolo de vínculo en radio de estación móvil y una capa de protocolo IS-95 de estación móvil.

27. El medio legible en máquina de la reivindicación 24, caracterizado porque la pluralidad de capas de protocolo de estación móvil incluye una pila de protocolo de comunicación de estación móvil.