MXPA02009369A - Method and apparatus for notifying a mobile station application of specified events. - Google Patents

Abstract

The present invention discloses a method and apparatus for notifying a mobile station application of a specified event 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 communication protocol stack or the mobile station application interface detects a specified event and invokes notification of the specified event to the mobile station application.

Description

METHOD AND APPARATUS TO NOTIFY THE APPLICATION OF A MOBILE STATION SPECIFIC EVENTS BACKGROUND 1. Field of the Invention This invention relates generally to the field of wireless communications. More particularly, the present invention relates to a method and apparatus for notifying the application of a mobile station of a specific event 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 paved the way for mobile computing. Indeed, the popularity of mobile computing has placed greater demands on the current Internet infrastructure to provide mobile users with more support. The heart of this infrastructure is the packet-oriented Internet Protocol (IP) which provides several services, including packet routing and routing. (datagrams) between networks of local and wide area (LAN and WAN). The IP protocol is defined in the Request for Comments 791 (RFC 791) entitled, "SPECIFICATION OF THE PROTOCOL OF THE DARPA Internet PROGRAM FOR THE INTERNET PROTOCOL ", dated September 1981. The IP protocol is a network protocol that encapsulates data in IP packets for transmission, routing and routing information is fixed to the packet header. IP headers, for example, contain 32-bit addresses that identify the sending and receiving hosts.These addresses are used by intermediate routers to select a path through the network for the packet to its final destination to the intended address. In this way, the IP protocol allows packets that originate in any node of the Internet in the world to be routed to any other node in the Internet in the world, on the other hand, a transport layer is used, which comprises a Transmission Control Protocol (TCP) or a User Datagram Protocol (UDP), to direct particular applications. is that mobile users use mobile computers, such as laptops or handheld computers, in conjunction with wireless communication devices, such as cell phones or portable, to have access to the Internet. That is, just as users conventionally use "wireline" communication devices to connect their computers to land-based networks, mobile users will use wireless communication devices, commonly referred to as "mobile stations" (MS), to connect their mobile terminals to those networks. As used herein, the mobile station or MS will refer to any subscriber or 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 to, and often colocalized with, the BS / MSC 106, which may be a conventional wireless base station as is known in the art. Another standard protocol that directs the wireless data communication system is the 3rd Generation Partnership Project 2 ("3GPP2") entitled "WIRELESS IP NETWORK STANDARD", published in December 1999. The 3G Wireless IP Network Standard, by For example, it includes a Packet Data Service Node ("PSDN"), which works the same as IWF 108. There are several protocols that direct data communications between MS 110 and IWF 108. For example, the Interim the Association of the Telecommunications Industry (TIA) / Electronic Industries Association (EIA) IS-95, entitled "MOBILE STATION COMPATIBILITY STANDARD BASE STATION FOR BROADBAND WIDE BROADBAND EXTENDED SPECTRUM SYSTEM", published in July 1993, generally provides a standard for wideband broadband wireless communication systems. In addition, the TIA / EIA IS-707.5 standard, entitled "DATA SERVICE OPTIONS FOR BROADBAND EXTENDED SPECTRUM SYSTEMS: PACKET DATA SERVICES", published in February 1998, define the requirements for transmission capacity support. of packet data in TIA / EIA IS-95 systems and specifies the packet data bearer services that can be used for communication between MS 110 and IWF 108 via BS / MSC 106. Also, the TIA / EIA standard IS-707-A.5 entitled "DATA SERVICE OPTIONS FOR EXTENDED SPECTRUM SYSTEMS: PACKET DATA SERVICES" "and the TIA / EIA IS-707-A.9 standard entitled" DATA SERVICE FOR EXTENDED SPECTRUM SYSTEMS : SERVICES OF 'HIGH SPEED' PACKAGE DATA, both published in March 1999, also define requirements to support packet data transmission in TIA / EIA IS-95 systems, and 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 EXTENDED SPECTRUM SYSTEMS", published in July 1999. The IS-707.5 introduces communication protocol option models between the MS 110 and the BS / MSC 106 (the interconnection Um), and between the BS / MSC 106 and the IWF 108 (the interconnection L). For example, a Relay Model represents the situation where a link exists Point-to-Point Protocol (PPP) in the Um interconnection between MS 110 and IWF 108. The PPP protocol is described in detail in Request for Comments 1661 (RFC 1661), entitled "PROTOCOL POINT TO POINT (PPP)". FIGURE 2 (Previous Technique) is a diagram of the protocol stacks in each entity of the IS-707.5 Relay Model. On the far left side of the figure is a stack of communication protocol, shown in conventional vertical format, showing the protocol layers running on the MS 110. The protocol stack of the MS 110 is illustrated as if it were placed logically to the protocol stack of the BS / MSC 106 on the interconnection Um. The protocol stack of BS / MSC 106, in turn, illustrated as being logically connected to the protocol stack of IWF 108 over interconnection L. The operation described in FIGURE 2 is as follows: a protocol entity of the upper layer 200, such as an application program operating in the MS 110, has the need to send data over the Internet. A representative application can be a network browser program (for example, Netscape Navigator ™, Microsoft Internet Explorer ™). The network browser requests a Universal Resource Mapper (URL), such as the HIPERENLACE "http://www.Qualcomm.com/". A Domain Name System (DNS) protocol, also in the protocol of the upper layer 200, translates the name of a textual host www. Qualcomm com to a 32-bit IP numerical address by the use of a domain name resolution, which translates names to addresses on the Internet. The Hypertext Transfer Protocol (HTTP), which is also a protocol of the upper layer 200, constructs a GET message for the requested URL, and specifies that TCP will be used to send the message and for operations of the HTTP. The transport layer 202 uses port 80, which is known in the art as the destination port to route HTTP operations to the application. The TCP protocol, which is a protocol of transport layer 202, opens a connection to the IP address specified by the DNS and transmits the GET HTTP message to the application level. The TCP protocol specifies which IP protocol will be used to transport the message. The IP protocol, which is a protocol of the layer of the network 204, transmits the TCP packets to the specified IP address. The PPP, which is a protocol of the link layer 206, encodes the IP packets and transmits them to the relay layer protocol 208. An example of the relay layer protocol 208 may be the TIA / EIA standard. 232F illustrated, which is defined in "DATA INTERCONNECTION BETWEEN TERMINAL EQUIPMENT AND THE COMPUTER COMPLETING THE CIRCUIT OF 'DATA USING EXCHANGE OF BINARY DATA IN SERIES", published in October 1997. It should be understood that other standards or protocols may be used known to those skilled in the art to define the transmission through the layers. For example, other applicable standards may include the "SPECIFICATION OF THE UNIVERSAL SERIAL CHANNEL (USB), Revision 1.1", published in September 1998, and the "VERSION NUMBER 1.0A OF THE SPECIFICATION OF BLUETOOTH ", published July 1999. Finally, 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 about the interconnection Um. The RLP protocol 210 is defined in the IS-707.2 standard, entitled "DATA SERVICE OPTIONS FOR BROADBAND EXTENDED 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 PPP packets on the interconnection Um through an IS-95 layer 218, and then a layer of RLP 216. The relay layer protocol 220 passes it on the interconnection L to a relay layer protocol 228 over the IF 108. A link layer of the PPP protocol 226 over the IWF 108 receives the protocol PPP packets from the relay layer 228, and terminates the PPP connection between the MS 110 and IWF 108. The 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 its final routing, which in this scenario is www. Qualcomm com.

Assuming that the final destination of the IP packets generated by the MS 110 is not the IF 108, the packets are sent through the protocols of the network layer 224, and the protocols of the link layer 225 to the next router ( not shown) on the Internet. In this way, the IP packets of the MS 110 are communicated through the BS / MSC 106, and the IWF 108 to its intended destination in the Internet, in accordance with the relay model or relay of the IS-707.5 standard. Before a packet of the MS 110 reaches its destination, a data link connection must first be established. As specified in RFC 1661, this requires that each end of the point-to-point link (ie, PPP protocols 206 and 226) first send PPP Link Control Protocol (LCP) packets to establish, configure and test the connection of the data link. After the link has been established by the LCP, the PPP protocol 206 can then send 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 Request for Comment 1332 (RFC 1332), entitled "The PROTOCOL OF CONTROL OF THE PROTOCOL OF INTERNET PPP (IPCP) ", published in May 1992. Before the IPCP negotiation, however, an authentication phase may be necessary After each of the protocols of the network layer has been configured, the packets of each protocol of the network layer can be sent over the link between them.

B. Interconnection of Application Programs Most, if not all, processes that support the communication protocol stack on the MS 110 are executed by application programs. In general, conventional data networks employ interconnections of application programs (APIs) to allow application programs to run on one computer to communicate with application programs running on another computer. APIs use "connectors" that protect invoking applications against differences in underlying network protocols. To achieve interconnected communications, APIs include functions, which allow applications, for example, to open a connector, transmit data to the network, receive data from the network, and close the connector. Common network programming interconnections include the interconnection of Development of Berkeley Systems (BSD), operating under a UnixMR operating system, WindowsMR Connector Interconnects (WinSockR), which operates under a WindowsMR operating system. Because the BSD connectors do not support WinSock ™, the communication protocol stack in the wireless MS 110 (see FIGURE 2), a novel API support such as a stack is necessary. In particular, what is needed is a novel apparatus and method 10 to notify the MS 110 application of a specific event in a wireless communication system.

SUMMARY OF THE INVENTION The present invention solves the need 15 identified above providing a method and apparatus for a mobile station application for identifying specific events in a wireless communication system. In one implementation, the present invention includes an interconnection of Application program (API) that facilitates communications between a mobile station communication protocol stack, which communicates with a communication network, and a mobile station application. The communication protocol stack of the ? ^ mobile station or interconnection of the application of the mobile station detects a specific event and invokes the notification of the specific event to the application of the mobile station.

BRIEF DESCRIPTION OF THE DRAWINGS FIGURE 1 (Previous Technique) is a high-level block diagram of a system of wireless communication in which a mobile station connects to the Internet. FIGURE 2 (Previous Technique) schematically describes the protocol stacks in each entity of the TIA / EIA Relay Model IS-707.5. FIGURE 3 schematically describes the features of one embodiment of the present invention. FIGURES 4 and 5 are flow diagrams to detect a specific event. FIGURE 6 is a block diagram describing an asynchronous connection. FIGURE 7 is a block diagram describing an asynchronous connector input. FIGURES 8-10 are state diagrams of embodiments of the present invention.

DETAILED DESCRIPTION The embodiments of the present invention can be realized in a variety of implementations, including programs and programming systems, fixed instructions, and / or physical computing components. Consequently, the operation and behavior of the present invention will be described without specific reference to the code of the programs and programming systems or physical computing components, it should be understood that one skilled in the art would be capable of designing programs and programming systems and / or physical computing components for implementing the present invention, which notifies the application of the mobile station of a specific event, based on the description therein. FIGURE 3 describes an application 260, a communication protocol stack 280, and an API 270 with 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 calls, which are provided by the API 270. In other words, the API 270 allows the application 260 and the communication protocol stack 280 to operate in different processors and systems operational without compromising functionality. An expert in the art appreciate that several names are possible for the functions invoked without departing from the scope of the present invention. It should be noted that the communication protocol stack 280 contains a plurality of waiting waiting and waiting waiting stacks, which store data. The output functions read data from an application memory 260 for storing data in one of the send waiting rows of the communication protocol stack 280. The input functions read data from one of the reception waiting rows of the communication protocol stack 280 for storing the data in application memory 260. To illustrate the operation, 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 header of the IP packet indicates the transport, which can be TCP or UDP. On the basis of the number of destination ports specified in the header of the transport layer, the data is routed to the appropriate reception waiting queue of the communication protocol stack 280, which corresponds to a particular connector. The data can then be transmitted to the application 260.

In certain situations, it may be desirable to operate with packets that bypass the different layers of the protocol stack 280 to reduce the latency effect. Such packets include untreated packaged data, such as untreated IP packets, which lack destination information (i.e., destination port number). Therefore, the destination application may not be determined from unpatched IP packets. In such situations, the stack of the communication protocol 280 can transmit the received raw packets of IP to all registered connectors to support the IP protocol, for example. This allows the loaded data to be transmitted to the target application. A machine that grammatically analyzes an Internet Control Messaging Protocol (ICMP), which corresponds to IP packets, can also receive the unpatched packaged data. The well-known ICMP grammar analyzer is defined in RFC 792, entitled "INTERNET CONTROL MESSAGE PROTOCOL". It should be apparent from this description that the stack of the communication protocol 280, for example, processes the received packets before passing them from the stack to the application 260, which reduces the amount of de-encapsulation to be performed by the application 260.

In contrast, application 260 can transmit packaged data untreated over the Um interconnect, using the connectors, which facilitates communication between the stack of the communication protocol 280 and the application 260. In addition, the application 260 can transmit packed data without addressing the interconnection Um. In turn, the stack of the communication protocol 280 encapsulates the packed or untreated data, for example, in IP packets and transmits them over the interconnection Um. In this example, the communication protocol stack 280 provides an IP header and a sum check to generate the IP packets. For ICMP, on the other hand, a specific protocol type can be copied into the IP header. As stated above, application 260 can create a connector that allows data communications between at least one of protocol layers 202, 204, 206, 208, 210, 212 and application 260 to reduce the latency inherent in the use of the protocol. communication protocol stack 280. That is, the application 260 can create a connector that avoids the transport layer 202, the layer of the network 204 and the link layer 206, and thus, allows the application 260 to transmit data loaded to, or receive data loaded from the RLP 210 layer.

Also, application 260 can create a connector that allows application 260 to transmit loaded data to, or receive data loaded from, layer IS-95 212. In one embodiment, application 260 calls a function open_redlib () to open the stack of the communication protocol 280 and to assign an application identification. The application identification allows multiple applications to communicate with the stack of communication protocol 280 (ie, multitasking). As part of the call of the open_redlib () function, for example, application 260 specifies an indicator for a back-demand function of the network and a back-demand function of the connector. The back-demand function of the network is invoked to inform application 260 if specific events of the network subsystem have occurred (or have been allowed), such as reading from, writing to, and closing the traffic channel (ie Um). ) and / or a link layer (i.e., PPP 206). The back-demand function of the connector is invoked to inform the application 260 whether specific events of the connector have occurred (or have been allowed), such as reading from, writing to, and closing the transport layer (i.e., TCP). It will be apparent to a person skilled in the art that the communication network comprises at least one of the traffic channel, the link layer and the transport layer.

Once the stack of the communication protocol 280 has been opened, an openpppO function is invoked to initiate a connection of the network subsystem, which includes the traffic channel and the link layer. This is a broad application call, which does not depend on an individual connector. This, however, requires the identification of the application. After the establishment or failure of the network subsystem connection, the back-demand function of the network is invoked to provide a notification of a specific event. The subsystem of the network fails, for example, if the traffic channel is not established. In addition, the characteristics of the network subsystem can be established with a call to the net_ioctl () function. This call, for example, can specify the data rate of the connectors. Once the connection of the network subsystem is established, a connector (or connectors) can be created and initialized through a call to the connector () function. Before the connector functions can be used, however, a call to the connector () function can return to a connector descriptor. Then, application 260 can call a select_asinc () function to record specific events to receive an asynchronous notification. This record it can be implemented through application 260 as part of the function call, to specify the connector descriptor and a bit mask (ie, multiple events, OR 'ed together) of the specific events that require notification. If a specific event occurs (ie, is allowed), and is detected by the stack of the communication protocol 280 or the API 270, for example, the back-demand function of the connectors invoked to provide an asynchronous notification. The back-demand function can notify the application 260 of the specific events by using a signal, a message including a message about a remote procedure call (RPC), or an interruption of the physical computing components or programs and systems of programming. Once the application 260 is notified of the specific events, it can then call the function obteneNextEvent () to determine the specific events to be served. This function performs a mask of the specific elements that occurred for the specific connector descriptor. Also, clean the bits in the mask of the specific events that occurred. In this way, application 260 may not receive notification of specific events deactivated. Application 260 must register again (ie allow again) those specific events through a subsequent call to the select_asinc () function. In addition, the application 260 can change the specific events recorded by cleaning the corresponding bits in the bitmask of specific events. If the bits have already been cleaned in the bit mask, then the request is simply ignored. Briefly, event notification can be deactivated on a per-event basis, for example, through a call to the deselec_asinc () function. FIGURES 4 and 5 are flow diagrams to detect specific events. As shown in FIGURE 4, for example, the stack of communication protocol 280 expects application 260, of block 400, to record a specific event. After the specific event is recorded, the stack of the communication protocol 280, the block 402, selects a memory. In block 404, the specific event can be detected based on the information selected in block 402. In block 406, the write event is detected, for example, when the stack memory of communication protocol 280 ( that is, the wait queue to send) is available to accept a sufficient amount of data. The data can be transmitted from the application 260. If the selected information of the block 404 is not satisfactory (ie, the specific event has not occurred), then the communication protocol stack 280 continues to select the memory, as in the block 402. In FIGURE 5, the stack of communication protocol 280 expects application 260 to record a specific event, as indicated in block 500. During this time, an interrupt notification may be deactivated. Therefore, the interrupt notification may not be activated or activated. After a specific event is recorded, as in block 500, the interrupt notification, in block 502, can be activated based on the occurrence of the specific event. The read event, for example, occurs when data is written to the memory of the communication stack 280 (ie, the reception waiting queue). In this way, block 504, the read event is detected by the communication protocol stack 280 when it receives the interrupt notification, which was activated due to the occurrence of the event. The data stored in the stack memory of the communication protocol 280 can be from the communication network. Also, for the read event, the stored data can be transmitted to the application 260. Finally, the closing event detected when a connector is available for reuse because, for example, a data link connection, such as the transport layer , it's finished. The following asynchronous connection examples (see FIGURE 6) and an asynchronous input (see FIGURE 7) are provided to initiate the use of the notification of an asynchronous event. Referring to FIGURE 6, both the communication protocol stack 280 is entered and the back-demand functions are specified through a call to the open_redlib () function. The call to the function openpppO (A) initiates the connection of the subsystem of the network (B). After the connection of the network subsystem has been established, the back-demand function (C) is invoked to report the availability of the network subsystem. Assuming that a connector has been opened and assigned, a call to the connect () function (D) initiates a TCP (E) connection. In addition, application 260 calls the select function asinc () (F) to record the specific events to receive the notification. In this example, the specific event of interest is the writing event, which occurs after establishing a connection. After establishing the connection, the back-demand function is invoked if the specific event is registered in the mask. If so, then the back-demand function (G) is invoked to provide an asynchronous notification. Once the application 260 is notified, this call to the function obtainsnext () (H) to determine which specific event occurred (I). Also, this call cleans the event bits (that is, the write event) in the mask (J). Application 260 must record the subsequent notification of the specific event again by calling the function select_asinc (). In FIGURE 7, an illustration of a reading of the asynchronous connector is provided. To start the reading, application 260 makes a call to the reading function () (A). Assuming a lack of data to read, the application 260 calls the function select_asinc () (B) to register an event (ie, set the corresponding bit in the mask) to receive the notification. In this example, the specific event of interest is the reading event, which occurs when there is data to be read by the application 260.

After data storage in the reception waiting queue, the back-demand function is invoked if the read event in the mask is specified. If so, then the back-demand function (C) is invoked to provide an asynchronous notification. Once the application 260 is notified, this call to the function obtain next event () (D) to determine which event occurred (E). Also, this call clears the event bits in the mask (F). Application 260 must again allow subsequent notification of the event through the call to the select_asinc () function. Finally, to read the data stored in the reception waiting queue, application 260 makes the call to the read function () (G). In FIGURES 8-10, state machines of the embodiments of the present invention are illustrated. In Figures 8-9 it was assumed that the stack of communication protocol 280 is open, and the connection network subsystem (ie, traffic channel, and the link layer if necessary - the connectors untreated can avoid subsystems of the network) was established. One skilled in the art will appreciate that various names are possible for the states without departing from the scope of the present invention.

The state machine, which can transit asynchronously between states, controls (ie activates and deactivates) specific events, such as reading, writing and closing. Specific events can be deactivated at the start of the operation and can be activated in predetermined states to assist application 260 to identify the status of MS 110. Also, API 270 reports specific status messages that are particular (ie, not merely generic) to application 260 based on the state of API 270 and the type of function called by application 260. Specific status messages may reflect the state of the underlying communication network. Status messages are reported to application 260 as arguments to function calls, for example. In FIGURE 8, for example, a state diagram for a TCP connector of API 270 is illustrated. The initialized connector starts in the "null" state 800. The connector does not "exist" because it has not yet been assigned. The connector can be created and initialized through a call to the connector function (), which returns the descriptor of the connector to be used with the functions related to the connector After the function call connector (), the state machine transitions to a state of "initialization" 805. In the initialization state 805, the state machine again transitions to the null state 800 when it is finished the possibility of TCP connection by a call to the close function (). The call to the close () function frees all resources related to the connector. On the other hand, a call to the connect () function initiates the TCP connection and the transitions of the state machine to an "open" state 810. In the open state 810, the state machine transits to a "closed" state. "815 when; (1) a failure of the network subsystem occurs, (2) a failure to establish the TCP connection, or (3) a change of IP address. Also, after a call to the close () function, which terminates the TCP connection, the state machine transitions the connector to a "close" 820 state, while the termination procedures are initiated. Finally, the state machine transits to an "open" state 825 after the TCP connection is established. In open state 825, the connector opens to read and write. In particular, the writing event is allowed immediately, while the Read event is allowed on the basis of whether data is stored in the memory of the communication protocol stack 280. The state machine transits to the closed state 815 if: (1) a failure of the network subsystem occurs; (2) the establishment of the TCP connection fails; (3) an attempt to terminate the TCP connection, such as a TCP reset, an aborted TCP, or a closed TCP initiated by a network server; and (4) the change of the IP address. A TCP connection termination initiated by the application, such as by a call to the close () function, transitions the state machine to the closing state 820. In the closed state 815, the read, write and close events are all taxes. After a call to the close function (), which terminates the TCP connection, the state machine transits the connector to null state 800, which releases the connector and becomes available for reuse. In the closing state 820, the state machine transits to a "wait to close" state 830 if: (1) a failure of the network subsystem occurs; (2) the attempt to terminate the TCP connection, such as the TCP reset, or the closed TCP initiated by the network server; (3) an expiration of a timer v (4) the change of the IP address. For the protection against the delay in the termination of the TCP connection, the API 270 implements the timer, which is activated after the start of the termination of the TCP connection. As it is observed, the expiration of the timer, transitions the state machine to the state of waiting to close 830. In the state of waiting to close 830, a call to the close function () terminates the TCP connection and transits the machine from state to a null state 00. The close event is imposed in this state 830. Tables 1-3 illustrate specific status messages supported by API 270. In the null state (not shown in Tables 1-3), a specific status message, which it is descriptive, that "no additional resources are available" can be reported to application 260.

Table 1 Table 1 (Continued) Close There is no TCP connection due to the absence of the origin attempt, or the connection attempt failed Wait for no TCP connection due to the Close absence of the origin attempt, or connection attempt failed; o Generic network error; the underlying network is not available Closed Generic network error; the underlying network is not available; The connection attempt was rejected due to a server reset; Delay of the connection in progress; o The IP address at the network level changed, which caused the TCP connection to reset, due to a resynchronization of PPP.

Table 2 State Specific Status Message for a type of I / O Function Table 2 (Continued) Initialize No TCP connection due to no origin attempt, or connection attempt failed Open If this was a call from the block function, the operation would be blocked Open If this was a call from the lock function, the operation will be blocked (number of read / write bytes) Close The TCP connection does not exist due to the absence of origin attempt, or the connection attempt failed Wait for TCP connection does not exist due to the Close absence of origin attempt, or failed connection attempt; o Generic network error; the underlying network is not available Closed Generic network error; the underlying network is not available; The server resets the connection; receiving a server reset; The TCP connection aborted due to a delay or other reason; or Table 2 (Continued) Closed The TCP connection does not exist due to the absence of an origin attempt, or the failed connection attempt.

Table 3 Status State Specific Message for a type of Initialization Success Function - no error condition was reported Open If a call is out of the lock function, the operation will be blocked Open If a call is out of the lock function, the operation will be blocked Close If a call is out of the lock function, the operation will be blocked Wait for Success - no error condition reported Close Closed Success - no error condition reported.

By way of example, FIGURE 9 illustrates a state diagram for a UDP connector of API 270. The initialized connector starts in a "null" state 900. As noted above with respect to null state 800, the connector does not "exist". "because it has not been assigned. The connector can be created and initialized through a call to the connector function (), which returns the connector writer to be used with the functions related to the connector. After the call to the connector function (), the state machine transits to an "open" state 905. In the open state 905, the connector is open for reading and writing. In articulate, the write event is allowed immediately, while the read event is allowed on the basis of whether the data is stored in the memory of the communication protocol stack 280. The state machine transits to a "closed" state 910 when failures occur in the network subsystem. A UDP connection termination initiated by the application, such as by a call to the close function () transits the state machine to the null state 900. In the closed state 910, the read, write and close events are all allowed. After a call to the close function (), which terminates the UDP connection, the state machine transitions the connector to the null state 900, which releases the connector and makes it available for reuse. Tables 4-6 illustrate specific status messages supported by API 270. In the null state (not shown in Tables 4-6), the specific status message that "no additional resources are available" as set forth above, may be reported to application 260.

Table 4 Table 5 State Status message specified for a 1/0 function type Open If this was a blocking function call, the operation would be blocked (number of read / write bits) Closed Generic network error; the underlying network is not available Table 6 Status Specific status messages for a type of closing function Table 6 (Continued) Open Success - no error condition reported Closed Success - no error condition reported FIGURE 10 illustrates a state diagram for controlling subsystems of the network, such as the traffic channel (i.e., Um) and the link layer (i.e., PPP 206). A call to the function abrir_redlib () opens the subsystem of the network, and initializes a connector in a state "closed" 1000. A call to the function of opening PPP () initiates the connection of the subsystem of the network, which transients the connector to an "open" state 1005. Also, a page to the MS 110 for an incoming PPP call transports the connector to the open state 1005. In both cases, after successful negotiation, the MS 110 attempts to synchronize and establish the RLP and PPP through the traffic channel. In the opening state 1005, the connector transits to an "open" state 1010 to establish the connection of the network subsystem. On the other hand, the connector 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 invoked to identify events specific by the application 60, such as reading, writing and closing, which are allowed. At this time, the MS 110 can communicate through the traffic channel. The connector, however, transits to the closed state 1000 when failures of the network subsystem occur, which invokes the back-demand function. A termination of the network subsystem connection initiated by the application, such as a call to the close function (), causes the connector to transit to a "close" state 1015. In the closing state 1015, the connector transits to the closed state 1000 when the connection of the network system is terminated. In the closed state 1000, the back-demand function is invoked to identify the events specified 260 by the application that are allowed. Table 7 illustrates specific status messages that correspond to particular function calls, and that are supported by API 270.

Table 7 Function call Specific status messages (and description) Table 7 (Continued) connector () Address not supported; create a connector and Application Identifier does not return a valid; descriptor The protocol is of the wrong type to connect the connector; Invalid or unsupported connector parameter; Protocol not supported; o No more available connector resources Connect () If this was a call from the connection lock function start, the operation TCP would be blocked; Invalid connector descriptor; The connection attempt was rejected due to the reception of a server reset; Connection delay; The application's memory is not part of the valid address space; invalid size specified for the address length or message length; Table 7 (Continued) Connect () The IP address at the network level Starts TCP connection change, which caused that the TCP connection will be readjusted, due to a resynchronization of the PPP; Connection in progress; Connector descriptor already connected; Generic network error; the underlying network is not available; Invalid server address specified; Address already in use; o Destination address required abrirppp () If this is a call from the set a blocking function, the network connection operation will block it; Invalid application identifier specified; o Termination of the network connection in progress red_ioctl () Fixed application identifier the specified invalid; Characteristics of invalid request or parameter; the network Network connection established; o Network connection in progress Table 7 (Continued) abrir_redlib () No more applications available the stack of the exceeded the maximum number of open applications protocol communication close-redlib () Application identifier closes the specified invalid stack; protocol There are assigned connectors; or communication The network connection is still established unite () Connector descriptor specified for invalid connectors; client, joins an unspecified specified operation or local address and the unsupported one; value of a port Address already in use; to the Operation not valid connector; o Invalid specified address parameters close () Specified connector descriptor closes an invalid connector; or to release this If this was a call in the to be reused lock function, the operation would be blocked Table 7 (Continued) closeppp () If a call is outside the Close the connection blocking function, the operation of the network would be blocked; Invalid application identifier specified; o Termination of the connection of the network in progress state of the network () Application identifier Reports the specified state not valid; The underlying network connection is not available network; Network connection established and available; Progress network connection- Termination of the network connection in progress; Non-CDMA service (ie, traffic channel) available; CDMA service available, but the origin failed because the base station does not support the service option; or Table 7 (Continued) state of the network () CDMA service available, but the Report source state failed, however, not due to the connection to which the base station does not support the network service option. selec_asinc () Specified connector descriptor Registers specific invalid events for a particular connector obtenextne Connector descriptor specified event () not valid; or Gets the following application identifier specified invalid connector descriptor and events that have occurred write () Specified connector descriptor writes an invalid number; specific There is no TCP connection; bytes-memories The server reset the intermediate TCP connection; contiguous or not TCP connection aborted due to contiguous delay or other failure; Table 7 (Continued) write () The IP address at the network level writes a number changed, which caused the TCP specific connection to be reset, due to a byte-memory asynchronization of the PPP; intermediate TCP connection closed; contiguous or not Network not available; contiguous Invalid application buffer as part of the address space; o No free buffers available for writing read () Specified connector descriptor read an invalid number; specific There is no TCP connection; bytes-memories The server reset the intermediate TCP connection; contiguous or not TCP connection aborted due to contiguous delay or other failure; The IP address at the network level changed, which caused the TCP connection to be reset, due to an asynchronization of the PPP; TCP connection closed; ? 2 Table 7 (Continued) read () Network not available; read a number Non-specific application buffer valid as part of the byte space-address memory; intermediates Without free intermediate memories contiguous or not available for reading; or contiguous End of the received file marker will send () Connector descriptor to send an invalid specified number; byte-specific Address family not reported; Without free intermediate memories available for writing; Network not available; Application buffer does not validate as part of the address space; Specified option not supported; o Requested destination address recvde () Connector descriptor reads a number specified not valid; byte-specific Address family not reported; Table 7 (Continued) recvde () Without free buffers it reads a number available for writing; Network specific not available; bytes Invalid application buffer as part of the address space; o Specified option not supported In another embodiment, the state machine can read a machine-readable medium that comprises encoded information, such as a program code and coded programming systems, to render the process described above that notifies an application of the mobile station of the event specific. The machine-readable medium can accept the encoded information of a storage device, such as a memory or a storage disk, or of the communication network. Also, the machine-readable medium can be programmed with the encoded information when the medium is manufactured. The machine may comprise at least one of the application 260, the stack of the communication protocol 280, and the API 270, while the machine readable medium may comprise a memory or storage disk.

Although this invention has been shown in relation to particular modalities, it should not be considered limited. Rather, the invention is limited only by the scope of the appended claims and their equivalents. It is noted that in relation to this date, the best method known to the applicant to carry out the aforementioned invention, is that which is clear from the present description of the invention.

Claims (24)

1. CLAIMS Having described the invention as above, the content of the following claims is claimed as property. 1. A method for notifying an application of a mobile station of a specific event, the method is characterized in that it comprises: communication between a stack of the mobile station communication protocol and a communication network; communication between the stack of the communication protocol of the mobile station and the application of the mobile station through the interconnection of the application of the mobile station; detecting, by means of at least one of the stack of the communication protocol of the mobile station and the interconnection of the application of the mobile station, the specific event; and invoke the notification of the specific event to the application of the mobile station. 2. The method according to claim 1, characterized in that it further comprises invoking an asynchronous notification. 3. The method according to claim 1, characterized in that the invocation of the notification comprises a back-demand function. 4. The method according to claim 1, characterized in that it further comprises notifying the application of the mobile station of the specific event by means of a signal. 5. The method according to claim 1, characterized in that it also comprises notifying the application of the mobile station of the specific event by means of a message. 6. The method according to claim 1, characterized in that it also comprises notifying the application of the mobile station of the specific event by means of an interruption. The method according to claim 3, characterized in that the back-demand function is invoked by events of the subsystem of the network. 8. The method according to claim 3, characterized in that the back-demand function is invoked by the connector events. 9. An apparatus for notifying an application of a mobile station of a specific event, the apparatus is characterized in that it comprises: a stack of the mobile station communication protocol for communicating with a communication network; and a mobile station application interconnect to facilitate communications between the stack of the communication protocol of the mobile station and the application of the mobile station, where at least one of the stack of the communication protocol of the mobile station and the interconnection of the application of the mobile station is adapted to detect the specific event, where notification of the specific event to the application of the mobile station is invoked. The apparatus according to claim 9, characterized in that the notification includes an asynchronous notification. The apparatus according to claim 9, characterized in that the notification comprises a back-demand function. 12. The apparatus according to claim 9, characterized in that the notification is communicated by a signal. The apparatus according to claim 9, characterized in that the notification is communicated by a message. 14. The apparatus according to claim 9, characterized in that the notification is communicated by an interruption. 15. The apparatus according to claim 11, characterized in that the back-demand function is invoked by the events of the network subsystem. 16. The apparatus according to claim 11, characterized in that the back-demand function is invoked by connector events. 17. A means readable by a machine, characterized in that it comprises encoded information, which when read by a machine, produces the processes of: communication between a stack of the communication protocol of the mobile station and a communication network; communication between the stack of the communication protocol of the mobile station and a mobile station application through an application interconnection of the mobile station; detecting, by means of at least one stack of the mobile station communication protocol and the application interconnection of the mobile station, a specified event; and invoke the notification of the specific event to the application of the mobile station. 18. The means readable by a machine according to claim 17, characterized in that it further comprises invoking an asynchronous notification. 19. The means readable by a machine according to claim 17, characterized in that the notification comprises a back demand function. The means readable by a machine according to claim 17, characterized in that it also comprises notifying the application of the mobile station of the specific event by means of a signal. The means readable by a machine according to claim 17, characterized in that it also comprises notifying the application of the mobile station of the specific event by means of a message. 22. The means readable by a machine according to claim 17, characterized in that it also comprises notifying the application of the mobile station of the specific event by means of an interruption. 23. The means readable by a machine according to claim 19, characterized in that the back-demand function is invoked by the events of the network subsystem. The means readable by a machine according to claim 19, characterized in that the back-demand function is invoked by connector events.