MXPA02009507A - Method and apparatus for a mobile station application to identify specified status messages. - Google Patents

Abstract

The present invention discloses a method and apparatus for a mobile station application to identify specified status messages in a wireless communication system. The present invention includes an application program interface (API) that facilitates communications between a mobile station communication protocol stack, which communicates with a communication network, and a mobile station application. The mobile station application calls a function. The API selects at least one of specified status messages based on its state and the function called. The API then reports to the mobile station application the selected specified status messages.

Description

METHOD AND APPARATUS FOR A MOBILE STATION APPLICATION TO IDENTIFY SPECIFIED STATE MESSAGES BACKGROUND 1. Field of the invention This invention is generally related to the field of wireless communications. More particularly, the present invention relates to a novel method and apparatus that allows a mobile station application to identify messages of specified status in a wireless communication system. 2. Description of the Related Art A. Wireless Communications Recent innovations in wireless communication and computer-related technologies, as well as the unprecedented growth of Internet subscribers, have overcome the initial difficulties of mobile computing. In fact, the popularity of mobile computing has determined great demands on the current Internet infrastructure to provide mobile users with more support. The life blood of this infrastructure is the Internet Protocol (IP), oriented by packets that provide various services, including packet routing and routing (datagrams) between local and wide area networks ( LANs and ANs, for its acronym in English). The IP protocol is defined in Request For Comment 791 (RFC 791) entitled, "INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECI FICATION", dated September 1981. The IP protocol is a network layer protocol that encapsulates data in IP packets for transmission. The routing and routing information is fixed to the pack header. IP headers, for example, contain 32-bit addresses that identify the information distributors, senders and receivers. These addresses are used by intermediate routers to select a path through the network to direct the packet to its final destination and the intended address. In this way, the IP protocol allows packets that originate in any Internet node in the world to be routed to any other Internet node in the world. On the other hand, a transport layer is used, which comprises either a Protocol for Transmission Control (TCP) or a User Daphraggram Protocol (UDP) to address particular applications. The current trend is for mobile users to use mobile computers, such as laptops or handhelds, in combination with wireless communication devices, such as, for example, telephones, cell phones or laptops, which have access to the Internet. That is, when users conventionally use devices for "wireless" communication, to connect their computers to land-based networks, mobile users will use wireless communication devices, commonly referred to as "mobile stations" (MS, for their acronyms in English), to connect their mobile terminals to these networks. In the sense in which it is used herein, the mobile station or MS will refer to any subscriber station in the public wireless radio network. Figure 1 (prior art) illustrates a high level block diagram of a wireless data communication system in which the MS 110 communicates with an Interconnect Function (IWF) 108 via a Base Station / Mobile Switching Center (BS / MSC) 106. The IWF 108 serves as the access point to the Internet. The IWF 108 is coupled and often located with BS / MSC 106, which may be a conventional wireless base station as is known in the art. Another standard protocol addressed to the wireless data communication system is the 3rd Generation Partnership Project 2 ("3GPP2") entitled "IRELESS IP NETWORK STANDARD", published in December 1999. The 3G IP Wireless Network Standard, for example, includes a Data Pack Service Node ("PDSN"), which functions similarly as IWF 108. There are several protocols that direct data communications between MS 110 and IWF 108. for example, Interim Standard IS-95 of the Telecommunications Industry Association (TIA) / Electronic Industries Association (EIA), entitled "MOBILE STATION-BASE STATION COMPATIBILITY STANDARD fOR DUAL-MODE WIDEBAND SPREAD SPECTRUM CELLULAR SYSTEM", published in July of 1993, generally provides a standard for wide-band stepped spectrum wireless communication systems. In addition, the TIA / EIA IS-707.5 standard, entitled "DATA SERVICE OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: PACKET DATA SERVICES," published February 1998, defines requirements for support transmission capacity of data packets in TIA / EIA IS-95 systems and specifies the services that carry data packets that can be used for communication between MS 110 and IWF 108 via BS / MSC 106. Also, the TIA / EIA IS-707-A standard .5 entitled "DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS: PACKET DATA SERVICES," and the TIA / EIA-IS-707 A.9 standard, entitled "DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS: PACKET DATA HIGH-SPEED SERVICES" both published in March 1999, also define the requirements for the support of transmission of data packets in the TIA / EIA IS-95 systems. In addition, another standard protocol that directs communications between the MS 110 and the IWF 108 is the TIA / EIA IS-2000, entitled "INTRODUCTION TO CDMA 2000 STANDARDS FOR SPREAD SPECTRUM SYSTEMS", published in July 1999. The IS-707.5 introduces models of option for communication protocol between the MS 110 and the BS / MSC 106 (the Um interface), and between the BS / MSC 106 and the IWF 108 (the L interface). For example, a Relay Model represents the situation where there is a Point-to-Point Protocol (PPP) link on the Um interface between MS 110 and IWF 108. The PPP protocol is described in detail in Request for Comments 1661 ( RFC 1661), entitled "THE POINT-TO-POINT PROTOCOL (PPP)". Figure 2 (prior art) is a diagram of the protocol stacks in each entity of the IS-707.5 Relay Model. At the far left of the Figure is a stack of communication protocols, shown in the conventional vertical format, showing the protocol layers running on the MS 110. The MS 110 protocol stack is illustrated to be logically connected to the BS / MSC 106 protocol stack on the Um interface. The BS / MSC protocol stack 106, in turn, is illustrated to be logically connected to the IWF protocol stack 108 over the L interface. The operation shown in Figure 2 is as follows: a top layer protocol entity 200, such as, for example, an application program that runs on MS 110, has the need to send data on the Internet. A representative application could be a web browsing program (for example, Netscape Navigator ™, Microsoft Internet Explorer ™). The web browser requests a Universal Resource Locator (URL), such as, for example, HYPERLINK "http: // www. Qualcomm. Com /". A Domain Name System (DNS) protocol, also in the upper layer protocol 200, translates the name of the textual host www. Qualcomm com to a 32-bit numeric IP address by using a domain name resolution, which translates names for addresses on the Internet. The Protocol for Hypertext Transfer (HTTP), which is also a higher layer protocol 200, constructs a GET message for the requested URL, and specifies which TCP will be used to send the message and for the HTTP operations . The transport layer 202 uses port 80, which is known in the art, as the destination port for routing HTTP operations to the application. The TCP protocol, which is a transport layer protocol 202, opens a connection to the IP address specified by the DNS and transmits the HTTP GET message at the application level. The TCP protocol specifies that the IP protocol will be used to transport messages. The IP protocol, which is a network layer protocol 204, transmits the TCP packets to the specified IP address. The PPP, which is a link layer protocol 206, encodes the IP packets and transmits them to the relay layer protocol 208. An example of the relay layer protocol 208 may be illustrated by the TIA / EIA-232F standard, which is defined in "INTERFACE BETWEEN DATA TERMINAL EQUIPMENT AND DATA CIRCUIT TERMINATING EQUIPMENT EMPLOYING SERIAL BINARY DATA INTERCHANGE", published in October 1997. It should also be understood that other standards or protocols known by technicians with normal experience in this field can be used to define the transmission through the layers. For example, other standards that may apply may include the "UNIVERSAL SERIAL BUS (USB) SPECIFICATION, Revision 1.1", published in September 1998, and the "BLUETOOTH SPECIFICATION VERSION 1.0A CORE", published in July 1999. Lastly , the relay layer protocol 208 passes the PPP packets to a Radio Link Protocol (RLP) 210 and then to the IS-95 protocol 212 for transmission to the BS / MSC 106 over the Um interface. The RLP protocol 210 is defined in the IS-707.2 standard entitled "DATA SERVICE OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: RADIO LINK PROTOCOL", published in February 1998, and the IS-95 protocol is defined in the IS-95 standard identified above. . A complementary relay layer protocol 220 on the BS / MSC 106 receives the PPP packets on the Um interface through the IS-95 layer 218 and then an RLP layer 216. The relay layer protocol 220 passes them over the L interface towards a relay layer protocol 228 over the IWF 108. A PPP protocol link layer 226 over the IWF 108 receives the PPP packets from the relay layer protocol 228, and terminates the PPP connection between the MS 110 and the IWF 108. packets are passed from the PPP layer 226 to an IP 224 layer on the IWF 108 for the examination of the IP packet header for a final routing, which in this scenario is www. Qualcomm com. Assuming that the final destination of IP packets generated by MS 110 is not IWF 108, packets are routed through network layer protocols 224, and link layer protocols 225 to the next router (not shown ) on the Internet. In this way, the IP packets coming from the MS 110 communicate through the BS / MSC 106, and the IWF 108 towards its intended target in the Internet according to the relay model of the IS-707.5 standard. Before the MS 110 packets reach their destination, the data link connection must first be established. As specified in RFC 1661, this requires each end of the point-to-point link (ie, PPP protocols 206 and 226) to first send the PPP Link Control Protocol (LCP) packets with In order to establish, configure and test the data link connection. After the link has been established by the LCP, the PPP protocol 206 can then send the Network Control Protocol (NCP) packets to configure the network layer protocols 204 and 224. the NCP for the IP in the PPP links is the IP Control Protocol (IPCP). The IPCP is described in detail in Petition for Comments 1332 (RFC 1332), entitled "THE PPP INTERNET PROTOCOL CONTROL PROTOCOL (IPCP)", published in May 1992. Before the IPCP negotiation, however, a phase may be necessary of authentication. After each of the network layer protocols has been configured, packets from each network layer protocol can be sent over the link between them.

B. Application program interface Most, if not all, processes that support the stack of communication protocols on the MS 110 are executed by the application programs. In general, conventional data networks use application program interfaces (APIs) to allow application programs to run on one computer to communicate with application programs running on another computer. The APIs use "plugins", which protect the calling applications from the differences in the protocols of the fundamental network. To achieve interconnected communications, APIs include functions, which allow applications, for example, to open an outlet, transmit data to the network, receive data from the network, and close the socket. Common network programming interfaces include the plug-in interface for Berkeley Systems Development (BSD) that operates in accordance with a UnixMR operating system, and the Windows ™ plug-in interface (WinSockMR), which operates in accordance with a WindowsMR operating system.

Because neither the BSD nor WinSockMR plugs support the stack of communication protocols in the wireless MS 110 (see Figure 2), a novel API is required to support this stack. In particular, what is needed is a novel method and apparatus for a mobile station application to identify specified status messages in a wireless communication system.

SUMMARY OF THE INVENTION The present invention addresses the need identified above by providing a method and apparatus for a mobile station application to identify messages of specified status in a wireless communication system. In one implementation, the present invention includes an application program interface (API) that facilitates communications between a mobile station communication protocol stack, which communicates with a communication network, and a mobile station application. The mobile station application requests a function. The API selects at least one of the status messages specified based on its status and the requested function. The API then reports to the mobile station application the specified status messages, selected.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 (prior art) is a high-level block diagram of a wireless communication system in which a mobile station is connected to the Internet. Figure 2 (prior art) schematically describes the protocol stacks in each entity of the TIA / EIA Relay Model IS-707.5. Figure 3 schematically represents the characteristics of an embodiment of the present invention. Figure 4 and 5 are flow diagrams to detect a specified event. Figure 6 is a block diagram representing an asynchronous connection. Figure 7 is a block diagram representing an asynchronous plug input. Figures 8-10 are state diagrams of the embodiments of the present invention.

DETAILED DESCRIPTION The embodiments of the present invention can be carried out in a variety of implementations, including software, firmware and / or hardware. Therefore, the operation and behavior of the present invention will be described without specific reference to software code or hardware components, it should be understood that someone with ordinary skill in the art could be able to design software and / or hardware to implement the present invention, which allows a mobile station application to identify the specified status messages, based on the description herein. Figure 3 depicts an application 260, a stack of communication protocols 280, and an API 270 within an MS 110. The application 260 and the communication protocol stack 280 (i.e., the protocol layers 202, 204, 206, 208, 210, 212) communicate through function requests, which are provided by API 270. In other words, API 270 allows application 260 and stack of communication protocols 280 to run on different processors and operating systems without compromising functionality. One skilled in the art would appreciate that various names are possible for the functions called without departing from the scope of the present invention. It should be noted that the communication protocol stack 280 contains a plurality of transmit queues and receive queues, which store data. The output functions read the data from a memory of the application 260 to store the data in one of the transmission queues of the communication protocol stack 280. The input functions read the data from one of the queues of reception of the data. communication protocol stack 280 for storing the data in the application memory 260. To illustrate the operation, the MS 110 receives IP packets. The communication protocol stack 280 of the MS 110 de-encapsulates the IP packets, and passes them to the transport layer 202 (see Figure 3). A field in the IP packet header indicates the transport, which can be either TCP or UDP. Based on the destination port number specified in the transport layer head, the data is routed to the appropriate receive queue of the communication protocol stack 280, which corresponds to a particular socket. The data can then be transmitted to the application 260. In certain situations, it may be convenient to operate with packets that bypass various layers of the protocol stack 280 to reduce the effects of latency. These packets include data packed in a row, such as, for example, IP packets in a row, which lack destination information (ie, destination port number). As such, the destination application may not be determined from the IP packets in a row. In these situations, the communication protocol stack 280 can transmit the IP packets received in a row for all registered sockets to support the IP protocol, for example. This allows the payload data to be transmitted to the target application. An Internet Control Messaging Protocol (ICMP) recognition machine, which responds to IP packets, can also receive data packed in a row. The well-known ICMP recognition machine is defined in RFC 792, entitled "INTERNET CONTROL MESSAGE PROTOCOL". It will be apparent from this description that the communication protocol stack 280, for example, processes the received packets before passing them to the stack for the application 260, which reduces the amount of de-encapsulation to be performed by the application 260. In contrast, the application 260 may transmit data packed in a row over the Um interface when using the plugs, which facilitates communications between the stack of communication protocols 280 and the application 260. In addition, the application 260 may transmit data packed in a row. on the Um interface. In turn, the communication protocol stack 280 encapsulates the data packed or packed in a row, for example, in the IP packets and transmits them over the Um interface. In this example, the communication protocol stack 280 provides an IP header and a checksum in order to generate the IP packets. For ICMP, on the other hand, a specified protocol type can be copied to the IP header. As stated above, application 260 can create a socket that allows data communications between at least one of the protocol layers 202, 204, 206, 208, 210, 212 and application 260 reduce the latency inherent in the use of the communications protocol stack 280. That is, the application 260 can create a plug that biased the transport layer 202, the network layer 204, and the link layer 206, and thus allowing the application 260 to transmit the payload data to the RLP layer 210 or to receive the payload data therefrom. Also, the application 260 can create a plug that allows the application 260 to transmit the payload data to the IS-95 212 layer or to receive payload data therefrom. In one embodiment, application 260 requests an open_netlib () function to open the communication protocol stack 280 and assign an application identification. The application identification allows multiple applications to communicate with the stack of communication protocols 280 (ie, multi-task). As part of the request for the open_netlib () function, for example, application 260 specifies an indicator for a network back-demand function and for a plug-in back-demand function. The network back-demand function is requested to inform the application 260 whether specified events of the network subsystem have occurred (or been enabled), such as reading from, writing to, and closing the traffic channel (i.e. Um) and / or a link layer (i.e., PPP 206). The plug-in back-demand function is requested to inform the application 260 if specified plug-in events have occurred (or have been enabled), such as for example read from, write to and close the transport layer (ie, TCP). It will be apparent to one skilled in the art that a communication network comprises at least one traffic channel, the link layer, and the transport layer. Once the communication protocol stack 280 has been opened, a pppopen () function is requested to initiate a network subsystem connection, including the traffic channel and the link layer. This is a broad application application, which does not depend on an individual plug. However, it requires application identification. At the time of the establishment or failure of the network subsystem connection, the network back-demand function is requested to provide a specified event notification. The network subsystem fails, for example, if the traffic channel is not established. In addition, the characteristics of the network subsystem can be adjusted with a request for the net_ioctl () function.

This request, for example, can specify the data rate of the plugs. Once the network subsystem connection is established, a plug (or plugs) can be created and initialized through a request for the plug () function. Before plug-in functions can be used, however, the plug-in request () can return to a plug-in descriptor. Then, application 260 may request an async_select () function to record the specified events to receive the asynchronous notification. This record can be implemented by application 260, as part of the function request, to specify the plug-in descriptor and a bit mask (ie, the OR 'ed together events) of the specific events that require notification. If a specified event occurs (ie, it is enabled), and is detected by a stack of communication protocols 280 or API 270, for example, the plug-in back-demand function is requested to provide an asynchronous notification. The back-demand function can notify the application 260 of the specified event by using a signal, a message, which includes a message about the remote procedure request (RPC), or a hardware or software interruption. Once the application 260 is notified of the specified event, then the getnextevent () function can be requested to determine the events specified for the service. This function returns a mask of the specified events that occurred for the specified plug descriptor. Also, clean the bits in the mask of the specified events that were presented. In this way, application 260 may not be a notification of greater reception of the specified events disabled. Application 260 must register again (ie, rehabilitate) these specified events through a subsequent request for the async_select () function. In addition, the application 260 can change the specified events recorded by cleaning the corresponding bits in the bitmask of the specified events. If the bit is already cleaned in the bit mask, then the request is simply ignored. In summary, event notification can be disabled on a per-event basis, for example, through a request for the async_deselect () function. Figures 4 and 5 are flow diagrams to detect the specified events. As shown in Figure 4, for example, the communication protocol stack 280 waits for the application 260, in block 400, to register a specified event. After the specified event is recorded, the communication protocol stack 280, in block 402, interrogates a memory. In block 404, the specified event can be eliminated based on the requested information of block 402. In block 406, the written event is detected, for example, when the memory of communication protocol stack 280 (i.e. the emission queue) is available to accept a sufficient amount of data. The data can be transmitted from the application 260. If the requested information of the block 404 is not satisfactory (ie, the specified event has not been presented), then the communication protocol stack 280 continues to interrogate the memory, as in the block 402. In Figure 5, the communication protocol stack 280 waits for application 260 to record a specified event, as indicated in block 500. During this time, an interrupt notification may be disabled. As such, the interrupt notification can not be activated or will be activated. After the specified event is recorded, as in block 500, the interrupt notification, in block 502, can be activated based on the occurrence of the specified event. The reading event, for example, occurs when the data is written to the memory of the communication protocol stack 280 (i.e., the reception queue). In this way, in block 504, the read event is detected by the communication protocol stack 280 when the interrupt notification is received, which was activated due to the occurrence of the event. The data stored in the memory of the communication protocol stack 280 can come from the communication network. In addition, for the read event, the stored data can be transmitted to the application 260. Finally, the closing event is detected when a plug is available for re-use due, for example, to the termination of a link connection of data, such as, for example, the transport layer. The following examples of an asynchronous connection (see Figure 6) and an asynchronous input (see Figure 7) are provided to illustrate the use of asynchronous event notification. Referring to Figure 6, both the communication protocol stack 280 is entered as the back-demand functions are specified through the request for function open_netlib (). The request for the pppopen () function (A) initiates the connection of the network subsystem (B). After the network subsystem connection has been established, the back-demand function is requested (C) to report the availability of the network subsystem. Assuming that a plug has been opened and assigned, a request for the connect () (D) function initiates a TCP (E) connection. In addition, application 260 requests the async_select () (F) function to record the events specified for the reception notification. In this example, the specified event of interest is the write event that occurs at the time of establishing a connection. At the time of establishing the connection, the back-demand function is requested if the specified event is registered in the mask. If so, then the back-demand function is requested (G) to provide an asynchronous notification. Once the 260 application is notified, the getnextevent () (H) function is requested to determine which specific event occurred (I). Also, this request clears the event bit (that is, the write event) in the mask (J). Application 260 must again record the subsequent notification of the specified event through the request for the async_select () function. In Figure 7, an illustration of an asynchronous plug reading is provided. To start reading, application 260 makes a request for the read () function (A). Assuming a lack of data for reading, application 260 requests the function async_select () (B) to register an event (ie, set the corresponding bit in the mask) to receive the notification. In this example, the specified event of interest is the read event, which occurs when there is data to be read by application 260. At the time of storing the data in the receive queue, the back-demand function is requested if the read event is specified in the mask. If so, then the back-demand function is requested (C) to provide an asynchronous notification. Once the 260 application is notified, the getnextevent () (D) function is requested to determine which event occurred (E). Also, this request clears the event bit in the mask (F). Application 260 must re-enable subsequent notification of the event through the request for the asyn_cselect () function. Finally, to read the data stored in the reception queue, application 260 makes the request for the function read () (G). In FIGS. 8-10, the state machines of the embodiments of the present invention are illustrated. In Figures 8-9, it is assumed that the communication protocol stack 280 is opened and the network subsystem connection is established (ie, the traffic channel, and the link layer if necessary-the plugs in a row by deviation of the network subsystem). One skilled in the art would appreciate that various names for states are possible without departing from the scope of the present invention. The state machine, which can perform asynchronously the transition between the states, controls (ie, enables and disables) the specified events, such as, for example, reading, writing and closing. The specified events can be disabled at the start of the operation and can be enabled in the default states to help the application 260 identify the status of the MS 110. Also, the API 270 reports the specific status messages that are particular ( say, not simply generic) to the application 260 based on the state of the API 270 and the type of function requested by the application 260. The specific status messages may reflect the state of the fundamental communication network. Status messages are reported to application 260 as arguments for function requests, for example. In Figure 8, for example, a state diagram for a TCP plug of API 270 is illustrated. The uninitial plug starts at the "zero" state 800. The plug does not "exist" because it has not yet been assigned . The plug can be created and initialized through a request for the socket () function, which returns the plug descriptor to be used with the functions related to the plug. After the request for the socket () function, the state machine goes to an "initialize" state 805. In the state of initializing 805, the state machine goes back to the zero state 800 each time the possibility of a TCP connection through a request for the function cióse (). The request for the function cióse () frees all resources related to plugs. On the other hand, a request for the connect () function initiates the TCP connection without the transitions to the state machine in an "open" state 810. In the open state 810, the state machine goes into a "closed" state "815 every time: (1) there is a failure in the network subsystem, (2) a failure to establish the TCP connection, or (3) a changed IP address. Also, after a request for the function cióse (), which terminates the TCP connection, the state machine passes to the socket in a state of "closing" 820, while the termination procedures are initiated. Finally, the state machine goes to an "open" 825 state at the time the TCP connection is being established. In the open state 825, the plug opens to read and write. In particular, the write event is enabled immediately, while the read event is enabled based on whether the data is stored or not in the memory of the communication protocol stack 280. The state machine goes to the closed state 815 each time: (1) there is a failure in the network subsystem; (2) the failure to establish the TCP connection, (3) an attempt to terminate the TCP connection, such as, for example, a TCP reset, an aborted TCP, or a closed TCP initiated by a network server; and (4) the change of the IP address. A termination of the TCP connection initiated in the application, such as for example by a request for the function cióse (), the transitions of the state machine to the closing state 820. In the closed state 815, all the events of reading, writing and closing. After a request for the function cióse (), which terminates the TCP connection, the state machine goes to the plug for zero state 800, which releases the plug and makes it available for reuse. In the closing state 820, the state machine goes into a "wait for closure" state each time: (1) a failure occurs in the network subsystem; (2) the attempt to terminate the TCP connection, such as, for example, the TCP reset, or the closed TCP initiated by the network server; (3) a term of a timer and (4) the change of the IP address. For protection against the delay in the termination of the TCP connection, API 270 implements the timer, which is activated at the time of the beginning of the termination of the TCP connection. As noted, the timer term passes from the state machine to the wait state by closing 830. In the wait state by closing 830, a request for the function cióse () terminates the TCP connection and the transitions to the host machine. state for zero state 800. The closing case is maintained in state 830. Tables 1-3 illustrate the specified status messages supported by API 270. In the zero state (not shown in Tables 1-3), a specified status message, which is descriptive, can be reported to application 260 that "no additional resources are available".

Table 1 Table 2 Table 3 By way of example, Figure 9 illustrates a state diagram for a UDP plug of API 270. The uninitialized plug starts in a "zero" state 900. As noted above with respect to zero state 800, the plug it does not "exist" because it has not been assigned. The plug can be created and initialized through a request for the socket () function, which returns the plug descriptor to be used with the functions related to the plug. After the request for the socket () function, the state machine goes into an "open" state 905. In the open state 905, the plug opens to read and write. In particular, the write event is enabled immediately, while the write event is enabled based on whether or not the data is stored in the memory of the communication protocol stack 280. The state machine goes into a state " closed "910 each time a network subsystem failure occurs. A UDP connection termination initiated in the application, such as, for example, by a request for the function cióse (), passes to the state machine for the zero state 900. In the closed state 910, all the events of reading are enabled, write and close. After a request for the function closef), which terminates the UDP connection, the state machine goes to the plug for zero state 900, which releases the plug and makes it available for reuse. Tables 4-6 illustrate the specified status messages supported by API 270. In the zero state (not shown in Tables 4-6), the status message specified that "additional resources are not available" as set forth above , can be reported to application 260.

Table 4 Status Specific status messages for a function type to connect Open Error condition reported without success Closed Generic network error is not available; fundamental network Table 5 State Specific status messages for an I / O function type Open If this was a request for the blocking function, the operation could be blocked (number of read / written bytes) Closed Generic network error is not available; fundamental network Table 6 Figure 10 illustrates a state diagram for controlling the network subsystem, such as, for example, the traffic channel (i.e., Um) and the link layer (i.e., PPP 206). A request for the open_netlib () function opens the network subsystem, and initializes a socket in a "closed" state 1000. A request for the pppopen () function initiates the connection of the network subsystem, which passes from the socket to a state of "aperture" 1005. Also, a radiolocation for the MS 110 by an incoming PPP request passes to the socket for the aperture state 1005. In both cases, at the time of a successful negotiation, the MS 110 attempts to synchronize and establish both the RLP as the PPP through the traffic channel. In the opening state 1005, the plug goes into an "open" state 1010 at the moment when the network subsystem connection is being established. On the other hand, the plug goes back to the closed state 1000 if the connection of the network subsystem is not established. In the open state 1010, the back-demand function is requested to identify for the application 1060 the specified events, such as, for example, read, write and close, which are enabled. At this time, the MS 110 can communicate through the traffic channel. However, the plug goes into the closed state 1000 each time a failure of the network subsystem occurs, which requests the back-demand function. A connection termination of the network subsystem initiated in the application, such as, for example, by a request for the function cióse (), passes from the plug to a "close" state 1015. In the closing state 1015, the plug passes to the closed state 1000 each time the connection of the network subsystem is terminated. In the closed state 1000, the back-demand function is requested to identify for the application 260 the specified events that were enabled. Table 7 illustrates the specified status messages that correspond to the particular function requests, and 'that are supported by the API 270.

Table 7 Function request Status messages specified (and description) socket () Address not supported; creates a socket and the application identifier returns to an invalid; descriptor The protocol is of the wrong type plug for the plug; Invalid or unsupported plug parameter; Protocol not supported; o No more available plug resources connect () If this was a request to start the connection blocking function, the operation TCP could be blocked; Descriptor of the invalid plug The connection attempt was rejected due to the reception of a server reset Connection out of time; The application's memory is not part of the valid address space; the invalid size specified for the length of the address or the length of the message; The IP address at the network level changes, which causes the TCP connection to reset, due to resynchronization PPP; Connection in progress; The descriptor of the plug is already connected; Error is not available generic network; fundamental network; Specified address of the invalid server; The address is already in use; or Destination address required; bind () Descriptor specified for invalid plug plugs; clients, an invalid or unsupported local address is attached. and a value of The address is already in use; Port to the socket Invalid operation; o The invalid address specified parameter () Descriptor specified to close an invalid plug; or to leave it free If this was a request to return to lock function, the operation used could be blocked pppclose () If this was a request to close the connection blocking function, the network operation could be blocked; Invalid application-specified identifier; o Termination of the network connection in progress netstatus () Specifier specified from the report the invalid application status; of the connection The fundamental network is not available network; Invalid plug-in application descriptor and events that have occurred write () Descriptor specified to describe an invalid plug-in number; specified from No existing TCP connection; bytes -memorias The server resets the intermediates • TCP connection; contiguous or not The TCP connection aborted due to contiguous weather out or other failure; IP address at the network level changed, which causes the TCP connection to be reset, due to a PPP resynchronization; TCP connection closed; Network not available, Invalid application buffer is part of the address space; None of the memories In another embodiment, a machine can read a machine readable medium comprising encoded information, such as, for example, encoded software code, to cause the processes described above to enable a mobile station application to identify specific status messages. The machine readable medium can accept the coded information from a storage device, such as, for example, a memory or a storage disk, or from the communication network. Also, the machine readable medium can be programmed with the information encoded when the medium is manufactured. The machine may comprise at least one application 260, a stack of communication protocols 280 and an API 270, while the machine readable medium may comprise a memory or a storage disk. Although this invention has been shown in relation to particular embodiments, it should not be considered limited in this way. Instead, the invention is limited only by the scope of the appended claims and their equivalents.

Claims (12)

1. NOVELTY OF THE INVENTION Having described the present invention, it is considered as a novelty and, therefore, the content of the following CLAIMS is claimed as property: 1. A method for a mobile station application to identify a plurality of messages from specific state, the method comprises: communication between a protocol stack for communication of mobile station and a communication network; communication between the protocol stack for mobile station communication and the mobile station application through a mobile station application interface; request a function by the mobile station application; selecting, via the mobile station application interface, at least one of the status messages specified based on the status of the mobile station application interface and the requested function; and reporting, via the mobile station application interface, to the mobile station application, the at least one of the specified status messages. The method according to claim 1, wherein the mobile station application reports to the mobile station application the at least one of the status messages specified by an argument of the requested function. The method according to claim 1, wherein the mobile station application interface comprises a plurality of states. 4. The method according to claim 3, wherein the mobile station application interface passes asynchronously between the states. 5. An apparatus for a mobile station application to identify a plurality of messages of specified status, the apparatus comprising: a stack of mobile station communication protocols for communicating with a communication network; a mobile station application to request a function; and a mobile station application interface for selecting at least one of the status messages specified based on the status of the mobile station application interface and the function that will be requested, wherein the mobile station application interface is adapted to allow communication between the mobile station application and the communication protocol stack of the mobile station, and wherein the application interface of the mobile station is adapted to report to the mobile station application in at least one of the messages of specified state. The apparatus according to claim 5, wherein the application interface of the mobile station is adapted to report to the application of the mobile station on at least one of the status messages specified by an argument of the requested function. The apparatus according to claim 5, wherein the application interface of the mobile station comprises a plurality of states. The apparatus according to claim 7, wherein the application interface of the mobile station is adapted to pass asynchronously between the states. 9. A machine-readable medium comprising encoded information, which when read by a machine causes the processes of: communication between a protocol stack for communication of the mobile station and a communication network; communication between the protocol stack for communication of the mobile station and an application of the mobile station through an application interface of the mobile station; request a function from the application of the mobile station; selecting, via the application interface of the mobile station, at least one of the status messages specified based on the status of the application interface of the mobile station and the requested function; and reporting, via the application interface of the mobile station, to the application of the mobile station the at least one of the specified status messages. 10. The machine-readable medium according to claim 9, wherein the application of the mobile station reports to the application of the mobile station the at least one of the status messages specified by an argument of the requested function. The method according to claim 9, wherein wherein the application interface of the mobile station comprises a plurality of states. The method according to claim 11, wherein the application interface of the mobile station passes asynchronously between the states.