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

Abstract

The present invention relates to a method and apparatus for a mobile station application for identifying a designated event in a wireless communication system. The present invention includes an application program interface (API) that facilitates communication between a mobile station communication protocol stack and a mobile station application in communication with a communication network. The mobile communication protocol stack or mobile station application interface detects the specified event and invokes notification of the specified event to the mobile station application.

Description

METHOD AND APPARATUS FOR NOTIFYING A MOBILE STATION APPLICATION OF SPECIFIED EVENTS}

A. Wireless Communications

In addition to the unprecedented increase in Internet subscribers, recent revolutions in wireless communications and computer related technologies have facilitated methods for mobile computing. Indeed, the popularity of mobile computing has increased the demands of the current Internet infrastructure to provide more support for mobile users. The vitality of this infrastructure is based on Packet Oriented Internet Protocol (IP), which provides several services including addressing and routing of packets (datagrams) between local and wide area networks (LANs and WANs). The IP protocol is defined in the September 1981 RFC 791 (Request For Comment 791) named "INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION".

The IP protocol is a network layer protocol that encapsulates data into IP packets for transmission. Addressing and routing information is appended to the header of the packet. The IP header contains a 32-bit address that identifies the sending and receiving host. This address is used by the intermediate router to select the network path from the intended address to the final destination of the packet. Therefore, the IP protocol allows packets generated at any Internet node to be routed to any other Internet node. On the other hand, a transport layer comprising either Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) is used to address a particular application.

The current trend is for mobile users to use mobile computers, such as laptop or palmtop computers, in connection with accessing the Internet to wireless communication devices such as cellular or portable telephones. That is, as a user typically uses a "wired" communication device to connect his computer to a land based network, a mobile user typically uses a "mobile station" (MS) to connect his mobile terminal to the network. We will use a wireless communication device referred to as. As used herein, a mobile station, or MS, will survey any subscriber station in a public wireless radio network.

1 (Prior Art) shows a high-order block diagram of a wireless data communication system in which MS 110 communicates with interaction function (IWF) 108 via a base station / mobile switching center (BS / MSC) 106. IWF 180 acts as an access point for the Internet. IWF 108 is coupled to and often co-located with BS / MSC 106, a known conventional wireless base station. Another standard protocol for addressing wireless data communication systems is the third generation partnership project 2 ("3GPP2"), named "WIRELESS IP NETWORK STANDARD" and released in December 1999. The third generation wireless IP network standard includes a packet data serving node (“PDSN”) that functions like the IWF 108.

There are several protocols that address data communication between the MS 110 and the IWF 108. For example, the Telecommunications Industry Association (TIA) / Electronic Industry Council (EIA) Interim Standard IS-, entitled "MOBILE STATION-BASE STATION COMPATIBILITY STANDARD FOR DUAL-MODE WIDEBAND SPREAD SPECTRUM CELLULAR SYSTEM", was released in July 1993. 95 provides a standard for wideband spread spectrum wireless communication systems. Furthermore, the standard TIA / EIA IS-707.5, entitled “DATA SERVICE OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: PACKET DATA SERVICES, published in February 1998, is a requirement for the support of packet data transfer capability on TIA / EIA IS-95 systems. And a packet data bearer service that can be used for communication between the MS 110 and the IWF 108 via the BS / MSC 106. Also, in March 1999, both were published and the "DATA SERVICE OPTIONS TIA / EIA IS-707-A.5 standard named FOR SPREAD SPECTRUM SYSTEMS: PACKET DATA SERVICES, and TIA / EIA IS-707- named "DATA SERVICE OPTIONS" HIGH-SPEED PACKET DATA SERVICES. A.9 defines the requirements for supporting packet data transmission in TIA / EIA IS-95 systems, and another standard protocol for addressing communication between MS 110 and IWF 108. Named "INTRODUCTION TO CDMA 2000 STANDARDS FOR SPREAD SPECTRUM SYSTEMS" A TIA / EIA IS-2000.

IS-707.5 introduces a communication protocol option model between MS 110 and BS / MSC 106 (Um interface) and between BS / MSC 106 and IWF 108 (L interface). For example, the relay model represents an environment where a point-to-point protocol (PPP) link exists on the Um interface between the MS 110 and the IWF 108. The PPP protocol is described in detail in RFC 1661 (Request for Comments 1661) named "THE POINT-TO-POINT PROTOCOL (PPP)".

2 (Prior Art) is a diagram of a protocol stack present at each entity of the IS-707.5 relay model. At the far left of the figure is a communication protocol stack, showing a protocol layer running on MS 110 and shown in a conventional vertical format. The MS 110 protocol stack is shown logically connected to the BS / MSC 106 protocol stack on the Um interface. The BS / MSC 106 protocol stack is shown logically connected to the IWF 108 on the L interface.

The operation shown in FIG. 2 is as follows: An upper layer protocol 200 entity, such as an application program running on MS 110, has a need to transfer data over the Internet. Representative applications may be web browser programs (eg, Netscape Navigator ^™ , Microsoft Internet Explorer ^™ ). The web browser requests a Universal Resource Locator (URL) such as the hyperlink " http://www.Qualcomm.com /". The Domain Name System (DNS) protocol of the upper layer protocol 200 translates the textual host name www.Qualcomm.com into a 32-bit numeric IP address using a domain name solution that translates the name into an address on the Internet. Hypertext Transfer Protocol (HTTP) is a higher layer protocol 200, constructs a GET message for the requested URL, and TCP is used to send the message for HTTP operation. The transport layer 202 uses a port 80, known as the destination port, for routing HTTP operations to the application.

The TCP protocol, transport layer protocol 202, opens a connection to the IP address specified by DNS and sends an application level HTTP GET message. The TCP protocol specifies that the IP protocol will be used for message transmission. The IP protocol, which is the network layer protocol 204, sends a TCP packet to the specified IP address. PPP, the link layer protocol 206, encodes the IP packet and sends it to the relay layer protocol 208. An example of a relay layer protocol 208 may be an example TIA / EIA-232F standard published in October 1997 and designated as “INTERFACE BETWEEN DATA TERMINAL EQUIPMENT AND DATA CIRCUIT TERMINATING EQUIPMENT EMPLOYING SERIAL BINARY DATA INTERCHANGE”. Other standard or known protocols may be used to specify the transport through the layer. For example, other applicable standards may include "UNIVERSAL SERIAL BUS (USB) SPECIFICATION, Revision 1.1" published in September 1998 and "BLUETOOTH SPECIFICATION VERSION 1.0A CORE" published in July 1999. Finally, the relay layer protocol 208 passes the PPP packet to the 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 specified in the IS-707.2 standard published in February 1998 and named "DATA SERVICE OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: RADIO LINK PROTOCOL", and the IS-95 protocol is described above. It is stated in

The complementary relay layer protocol 220 at the BS / MSC 106 receives the PPP packet by the IS-95 layer 218 and the RLP layer 216 via the Um interface. The relay layer protocol 220 passes it through the L interface to the relay layer protocol 228 on the IWF 108. PPP protocol link layer 226 on IWF 108 receives PPP packets from relay layer protocol 228 and terminates the PPP connection between MS 110 and IWF 108. Packets are passed from the PPP layer 226 to the IP layer 224 on the IWF 108 for final routing, the scenario being at www.Qualcomm.com .

If the ultimate destination of the IP packet generated by the MS 110 is not the IWF 108, the packet is routed to the next router (not shown) on the Internet via the network layer protocol 224 and the link layer protocol 225. Forwarded. In this manner, IP packets from the MS 110 are forwarded to the final destination of the Internet through the BS / MSC 106 and the IWF 108 in accordance with the IS-707.5 standard relay model.

Before the MS 110 packet reaches its destination, the data link connection must first be established. As specified in RFC 1601, this is the end of each point-to-point link (ie, PPP protocol 206,226) to send a PPP link control protocol (LCP) packet first to establish, configure, and test the data link connection. There is a need. After the link is established by the LCP, the PPP protocol 206 will then send a Network Control Protocol (NCP) packet to configure the network layer protocols 204,224. The NCP for the IP of the PPP link is the IP Control Protocol (IPCP). IPCP is described similarly in RFC 1332 (Request for Comment 1332), entitled "THEPPP INTERNET PROTOCOL CONTROL PROTOCOL (IPCP)" published in May 1992. Before the IPCP negotiation, an authentication step is required. After each network layer protocol is configured, packets from each network layer protocol can be sent over the link between them.

B. Application Program Interface

Most of the processes that support the communication protocol stack on the MS 110 are executed by an application program. In general, a typical data network uses an application program interface (API) to enable an application program running on a computer to communicate with an application program running on another computer. The API uses a "socket" that protects the calling application from differences in protocols of the underlying network. To achieve mutual networked communication, the API includes the ability to allow an application to open a socket, send data to the network, receive data from the network, and close the socket. Common network programming interfaces may include the Berkeley Systems Development (BSD) socket interface operating under the Unix ^™ operating system and the Windows ^™ socket interface (Winsock ^™ ) operating under the Windows ^™ operating system.

Because BSD sockets or WinSock ™ do not support the communication protocol stack at the wireless MS 110 (see FIG. 2), a new API is needed to support the stack. In particular, there is a need for a method and apparatus for a mobile station application that identifies a designated event in a wireless communication system.

The present invention relates to wireless communication. In particular, the present invention relates to a novel method and apparatus for enabling mobile station applications to identify specified events in a wireless communication system.

1 (Prior Art) is a high-order block diagram of a wireless communication system in which a mobile station connects to the Internet.

2 (Prior Art) schematically shows the protocol stack of each entity of the TIA / EIA IS-707.5 relay model.

3 schematically illustrates the characteristics of one embodiment of the present invention.

4 and 5 are flowcharts for detecting designated events.

6 is a block diagram for detecting an asynchronous connection.

7 is a block diagram for detecting asynchronous socket input.

8-10 are state diagrams of one embodiment of the present invention.

It is an object of the present invention to provide a method and apparatus for a mobile station application for identifying a designated event in a wireless communication system. In one embodiment, the present invention includes an application program interface (API) that facilitates communication between a mobile station communication protocol stack and a mobile station application in communication with a communication network. The API enables at least one of the specified events based on the state. The mobile station application then identifies the enabled event that was enabled.

One embodiment of the present invention may be implemented in various means including software, firmware and / or hardware. Therefore, the operation of the present invention will be described without particular description of the software code or hardware elements, and those skilled in the art will be able to design the software and / or hardware to carry out the present invention based on the description herein. The invention is an invention in which a mobile station application can identify a specified event.

3 shows an application 260, communication protocol stack 280, and API 270 within MS 110. Application 260 and communication protocol stack 280 (i.e., protocol layer 202,204,206,208,210,212) communicate by function calls provided by API 270. That is, API 270 is responsible for application 260 and communication protocol stack 280. It is possible to operate on different processors and operating systems without compromising in functionality, and those skilled in the art will understand that various names for the calling function are possible without departing from the scope of the present invention.

The communication protocol stack 280 includes a plurality of transmit queues and receive queues that store data. The output function reads data from the memory of the application 260 to store the data in one of the transmission queues of the communication protocol stack 280. The input function reads data from one of the receive queues of the communication protocol stack 280 to store the data in the memory of the application 260.

In order to explain the operation, the MS 110 receives an IP packet. The communication protocol stack 280 of the MS 110 decapsulates the IP packet and sends it to the transport layer 202 (see FIG. 3). The field of the IP packet header indicates transmission of either TCP or UDP. Based on the destination port number specified in the transport layer header, the data is routed to the appropriate receive queue of the communication protocol stack 280 corresponding to the particular socket. The data may then be sent to the application 260.

In certain circumstances, it may be desirable to operate with packets that bypass various layers of protocol stack 280 to reduce latency effects. This packet contains raw packetized data, such as raw IP packets that lack destination information (i.e. destination port number). As such, the destination application cannot be determined from raw IP packets. In such an environment, the communication protocol stack 280 will send the received raw IP packet to all registered sockets to support the IP protocol. This allows payload data to be sent to the destination application. An Internet Control Messaging Protocol (ICMP) parsing engine corresponding to an IP packet may receive raw packetized data. Known ICMP parsing engines are specified in RFC 792 named "INTERNET CONTROL MESSAGE PROTOCOL". For example, the communication protocol stack 280 processes the received packet before passing it to the application 260 on top of the stack, which reduces the amount of decapsulation to be processed by the application 260.

In contrast, application 260 may use sockets to send raw packetized data over the Um interface, which facilitates communication between communication protocol stack 280 and application 260. In addition, application 260 may transmit raw packetized data via the Um interface. Next, the communication protocol stack 280 encapsulates the packetized or raw packetized data into IP packets and transmits them through the Um interface. In the above example, communication protocol stack 280 provides an IP header and a checksum to generate an IP packet. In contrast, for ICMP, the specified protocol type can be copied to the IP header.

As discussed above, the application 260 may include at least one of the protocol layers 202, 204, 206, 208, 210, 212 and the application 260 to reduce latency inherent in the use of the communication protocol stack 280. You can create sockets that enable data communication between them. That is, the application 260 can create a socket that bypasses the transport layer 202, the network layer 204, and the link layer 206, so that the application 260 sends the payload data to the RLP layer 210. Can be sent to or received from. In addition, application 260 may create a socket through which application 260 may send or receive payload data to IS-95 layer 212.

In one embodiment, application 260 calls function open_netlib () to open communication protocol stack 280 and assign an application identification. Application identification allows several applications to communicate with the communication protocol stack 280 (ie, multi-tasking). For example, as part of a call to the function open_netlib (), the application 260 assigns a pointer to the network callback function and the socket callback function. The network callback function is used whenever (or whenever enabled) a network-specific event occurs, such as reading from, writing to, and closing a traffic channel (ie, Um) and / or link layer (ie, PPP; 206). Called to inform application 260. The socket callback function is called to notify the application 260 whenever a socket specified event occurs (or whenever it is enabled), such as reading from, writing to, and closing the transport layer (ie, TCP). It is apparent that the communication network includes at least one of a traffic channel, a link layer, and a transport layer.

Once the communication protocol stack 280 is opened, the function pppopen () is called to initiate a network subsystem connection that includes the traffic channel and link layer. This is an application scoped call that does not depend on individual sockets. However, application identification is required. When establishing or failing a network subsystem connection, the network callback function is called to provide the specified event notification. The network subsystem will fail if, for example, the traffic channel is not established. In addition, the network subsystem character can be set in a call to the function net_ioctl (). This call can specify the data rate of the socket.

Once the network subsystem connection is established, the socket (s) can be created and initiated by a call to the function socket (). However, before a socket function can be used, a call to the function socket () can return to the socket descriptor. The application 260 can then call the function async_select () to register the specified event to receive the asynchronous notification. Such registration may be performed by the application 260 as part of a function call to specify a bit mask (ie, with a multi-event OR ') and a socket descriptor of the specified event requiring notification. If the specified event occurs (ie, is enabled) and is detected by communication protocol stack 280 or API 270, the socket callback function is called to provide asynchronous notification. The callback function will notify the application 260 of the specified event using a signal, a message including a message via a remote mode call (RPC), or a hardware or software interrupt.

Once the application 260 notifies the specified event, it will call the function getnextevetn () to determine if the specified event will be serviced. This function returns the specified event mask generated for the specified socket descriptor. It also clears the bits of the specified specified event mask. Therefore, application 260 will no longer receive notification of disabled designated events. The application 260 must reregister (ie, re-enable) this specified event by subsequent calls to the function async_select ().

Application 260 will also change the registered designated event by clearing the corresponding bit of the bit mask of the designated event. If the bit has already been cleared in the bit mask, the request is simply ignored. In brief, event notification may be disabled on a per-event basis via a call to the function async_deselect ().

4 and 5 are flowcharts for detecting designated events. As shown in FIG. 4, communication protocol stack 280 waits for application 260 at block 400 to register for a designated event. After the designated event is registered, the communication protocol stack 280 polls the memory at block 402. At block 404, the designated event may be detected based on the polled information of block 402. At block 406, a write event is detected when the memory (ie, transmission queue) of the communication protocol stack 280 can accommodate a sufficient amount of data. Data may be sent from the application 260. If the polled information in block 404 is not satisfactory (ie, no designated event occurs), the communication protocol stack 280 continues to poll the memory as in block 402.

In FIG. 5, communication protocol stack 280 waits for application 260 to register the designated event as indicated at block 500. During this time, interrupt notification can be disabled. As such, the interrupt notification may or may not be triggered. After the designated event is registered, at block 502, an interrupt notification may be triggered based on the occurrence of the designated event, as in block 500. For example, a read event occurs when data is written to memory (ie, receive queue) of communication protocol stack 280. Thus, at block 504, a read event is detected by communication protocol stack 28 when receiving an interrupt notification triggered due to the occurrence of the event. Data stored in the memory of the communication protocol stack 280 is available from the communication network. In addition, for read events, the stored data can be sent to the application 260.

Finally, a closure event is detected when the socket is reusable because the data link, such as the transport layer, is terminated.

The following example of an asynchronous connection (see FIG. 6) and asynchronous input (see FIG. 7) is provided to illustrate the use of asynchronous event notification.

Referring to FIG. 6, the communication protocol stack 280 is all input and a callback function is designated by a call to the function open_netlib (). The call to function pppopen () (A) initiates a network subsystem connection (B). After the network subsystem connection is established, a callback function is called to report the availability of the network subsystem (C).

If the cache is open and allocated, a call to the function connect () (D) initiates a TCP connection (E). In addition, the application 260 calls the function async_select () to register the specified event regarding the receipt notification (F). In this case, an important designated event is a recording event that occurs when establishing a connection.

When establishing a connection, the callback function will be called if the specified event is registered in the mask. If so, the callback function is called (G) to provide asynchronous notification. Once the application 260 is notified, it will call the function getnextevent () (H) to determine (I) which specified event has occurred. This call also clears the bits of the event (ie write event) in the mask. The application 260 must re-register subsequent notifications of the events specified by the call to the function async_select ().

In FIG. 7, an example of asynchronous socket read is provided. To begin reading, application 260 makes a call to function read () (A). Assuming there is not enough data to read, application 260 calls function async_select () to register an event for receipt notification (i.e., set the corresponding bit of the mask) (B). In this case, an important designated event is a read event, which occurs when there is data to be read by the application 260.

When storing data in the receive queue, the callback function will be called if a read event is specified in the mask. If so, the callback function is called to provide asynchronous notification (C). Once the application 260 has been notified, the function getnextevent () is called (D) to determine (E) which event occurred. This call also clears the bit of the event of the mask (F). The application 260 must re-enable subsequent notification of the event by a call to the function async_select (). Finally, in order to read the data stored in the receive queue, the application 260 makes a call to the function read () (G).

8-10, a state machine of one embodiment of the present invention is shown. In Figures 8-9, communication protocol stack 280 is opened and a network subsystem connection is established (i.e., the traffic channel and, if necessary, the link layer-unprocessed socket may bypass the network subsystem). Those skilled in the art will appreciate that various names of states are possible without departing from the scope of the present invention.

State machines that can transition asynchronously between states control (ie, enable and disable) specified events such as reads, writes, and closures. The designated event may be disabled at the start of the operation and may be enabled in a given state to help the application 260 identify the state of the MS 110.

In addition, API 270 reports a specific status message specific to the application 260 (ie, simply not generic) based on the state of API 270 and the function type called by application 260. Assignment status messages reflect the state of the underlying communications network. Status messages are reported to the application 260 as a method of function invocation.

In FIG. 8, a state diagram for the TCP socket of the API 270 is shown. Uninitialized sockets start in the "null" state 800. The socket does not "exist" because it has not yet been allocated. A socket can be created and initiated by a call to the function socket () which returns a socket descriptor to use the socket-related function. After the function for function socket (), the state machine transitions to the "initial" state 805.

In the initial state 805, the state machine transitions back to the null state 800 whenever the possibility of a TCP connection is terminated by a call to the function close (). The call to the function close () releases all socket related resources. On the other hand, the call to call connect () initiates a TCP connection and transitions the state machine to the "opening" state 810.

In the opening state 810, the state machine transitions to (closed) state 815 whenever (1) a network subsystem failure occurs, (2) a TCP connection failure, or (3) a changed IP address is present. . Also, after the call to the function close () to close the TCP connection, the state machine transitions the socket to the "closed" state 820, and the termination procedure is initiated. Finally, the state machine transitions to an "open" state 825 when a TCP connection is established.

In the open state 825, the socket is open for reading and writing. In particular, while the write event is enabled immediately, the read event is enabled based on whether the data is stored in the memory of the communication protocol stack 280. The state machine is responsible for (1) a network subsystem failure, (2) a failure to establish a TCP connection, (3) an attempt to terminate a TCP connection, such as a TCP reset initiated by a network server, a TCP abort, or a TCP closure, and (4) Whenever a change in the IP address occurs, the state transitions to the closed state 815. The TCP connection termination initiated by the call to the function close () transitions the state machine to the closed state 820.

In the closed state 815, both read, write and close events are declared. After a call to the function close () which terminates the TCP connection, the state machine transitions to a null state 800 which allows the socket to be emptied and reused.

In the closed state 820, the state machine may (1) attempt to terminate a TCP connection, such as a network subsystem failure, (2) a TCP reset or a TCP close initiated by a network server, (3) the elapse of a timer, and (4) Whenever a change in the IP address occurs, the state transitions to the "closed wait" state 830. To protect against the delay of terminating a TCP connection, the API 270 runs a timer that is activated at the start of the TCP connection termination. The elapse of the timer transitions the state machine to the closed wait state 830.

In the closed wait state 830, a call to the function close () terminates the TCP connection and transitions the state machine to the null state 800. A closure event is declared in this state 830.

Table 1-3 shows the designated status messages supported by the API 270. In the null state (not shown in Table 1-3), a designated status message describing "No additional resources are available" will be reported to the application 260.

Table 1

condition The specified status message for the connection function type reset If it is a blocking function call, the operation will block. opening Connection in progress open Connection settings Closing TCP connection does not exist due to lack of attempts to occur or connection attempt failed Closed air TCP connection does not exist due to lack of attempt to occur or connection attempt failed; Or a general network error; Source network cannot be used Closure General network error; Source network not available; connection attempt rejected due to server reset; ongoing connection timeout; Or PPP resync caused a network-level IP address change that caused a TCP connection reset.

TABLE 2

condition Specified status message for the I / O function type reset TCP connection does not exist or connection attempt failed due to lack of attempts opening If it was a private blocking function call, the operation would block open If it was a blocking function call, the operation would block (read / bytes read) Closing TCP connection does not exist or connection attempt failed due to lack of creation attempt Closed air TCP connection does not exist due to lack of attempt to occur or connection attempt failed; Or a general network error; Source network cannot be used Closure General network error; Source network not available; server resets connection; Receiving a server reset; connection attempt rejected due to a server reset; TCP connection interrupted due to timeout or other reasons; Or TCP connection does not exist due to lack of attempt to create or connection attempt failed

TABLE 3

condition The specified status message for the closed function type reset Success-no error status reported opening If it is a blocking function call, the operation will block open If it is a blocking function call, the operation will block Closing If it is a blocking function call, the operation will block Closed air Success-no error status reported Closure Success-no error status reported

9 shows a state diagram for the UDP socket of the API 270. Uninitialized sockets start in a "null" state 900. As discussed above, with respect to the null state 800, the socket is not "present" because it is not allocated. The socket can be created and initiated by a function for function socket (), which returns a socket descriptor to use the socket related functions. After the call to the function socket (), the state machine transitions to the "open" state 905.

In the open state 905, the socket is open for reading and writing. In particular, the write event is immediately enabled and the read event is enabled depending on whether the data is stored in the memory of the communication protocol stack 280. The state machine transitions to a "closed" state 910 whenever a network subsystem failure occurs. Application-initiated UDP connection termination, such as a disallow call to function close (), causes the state machine to transition to a null state 900.

In the closed state 910, read, write and close events are all enabled. After a call to the function close () that terminates the UDP connection, the state machine transitions the socket to a null state 900 that frees the socket and allows it to be reused.

Table 4-6 shows the designated status messages supported by the API 270. In the null state (not shown in Tables 4-6), a designated status message may be reported to the application 260 indicating "no additional resources are available" as described above.

Table 4

condition The specified status message for the connection function type open Success-no error status reported Closure General network error; Source network cannot be used

Table 5

condition Specified status message for the I / O function type open If it was a blocking function call, the operation would block (read / bytes read) Closure General network error; Source network cannot be used

Table 6

condition Specified state message for closed function type open Success-no error status reported Closure Success-no error status reported

10 shows a state diagram for controlling network subsystems such as traffic channels (ie, Um) and link layer (ie, PPP 206). The call to the function open_netlib () opens the network subsystem and initializes the socket to the "closed" state (1000). The call to the function pppopen () initiates a network subsystem connection that transitions the socket to the "opening" state 1005. In addition, the page to MS 110 transitions the socket to the opening state 1005 by an input PPP call. In both cases, if successful negotiation, MS 110 synchronizes and establishes both RLP and PPP over the traffic channel.

In the opening state 1005, the socket transitions to an "open" state 1010 when a network subsystem connection is established. Meanwhile, the socket transitions to the closed state 1000 unless a network subsystem connection is established again.

In the open state 1010, a callback function is called to identify whether an application 1060 specified event, such as read, write, and close, is enabled. In this case, the MS 110 may communicate through a traffic channel. However, the socket transitions to the closed state 1000 whenever a network subsystem failure that calls the callback function occurs. The application initiation network subsystem connection termination by the call to the function close () transitions the socket to the "closed" state 1015.

In the closed state 1015, the socket transitions to the closed state 1000 whenever the network subsystem connection is terminated. In the closed state 1000, the callback function is called to identify whether the application 260 specified event is enabled.

Table 7 shows the designated status messages that correspond to specific function calls and are supported by the API 270.

TABLE 7

Function call (and description) The specified status message socket creation and socket descriptor return Address not supported; invalid application identifier; invalid type for protocol socket; invalid or unsupported socket parameter; unsupported protocol; Or no more socket resources are available connect () Initiate TCP connection If blocking function call, operation is blocked; invalid socket descriptor; connection attempt rejected due to receipt of server reset; connection timeout; application buffer is not part of the effective address space; address length or message length A valid size specified for the network level IP address change causing a TCP connection due to PPP resync; Connection in progress; socket descriptor pre-connected; general network error; Source network unavailable; invalid server addressed; address already in use; Or destination address request pppopen () Network Connection Setting If it is a blocking function call, the operation is blocked; invalid application identifier specified; Or terminate network connection net_ioctl () network character settings Invalid application identifier specified; invalid request or parameter; network connection established; Or network connection open_netlib () Open communication protocol stack No more applications available-maximum open applications not exceeded close_netlib () Close communication protocol stack Invalid identifier specified; presence of allocated socket; Or network connection is still set up bind () For client sockets, attaches a local address and port value to the socket Invalid socket descriptor specified; invalid or unsupported operation specified; address is already in use; invalid operation; Or invalid parameter specified close () close to empty the socket for reuse Invalid descriptor specified; Or, if it is a blocking function call, the operation is blocked pppclose () Close network connection If it is a blocking function call, the operation is blocked; invalid application identifier specified; Or termination of network connection in progress

netstatus () reports network connection status Invalid identifier specified; source network not available; network connection established and available; network connection in progress; network connection termination in progress; no CDMA (i.e. traffic channel) service is available; CDMA service available, However, creation failed because the base station does not support the service option; Or CDMA service available, but creation failed; But not because the base station does not support the service option async_select () Register the specified event for a specific socket Invalid socket descriptor specified getnextevent () Get the next socket script and the raised event. Invalid socket script specified; Or invalid application identifier specified write () writes to the specified number of byte-contiguous or non-contiguous buffers Invalid descriptor specified; TCP connection does not exist; server resets TCP connection; TCP connection is interrupted due to timeout or other failure; network level IP address is changed, which causes TCP connection to be reset due to PPP resync Network unavailable; application buffer is not a valid part of the address space; Or no free buffer available for writing read () Reads the specified number of byte-contiguous or noncontiguous buffers. Invalid socket descriptor specified; TCP connection does not exist; server resets TCP connection; TCP connection stopped due to timeout or other failure; network level IP address is changed, which resets TCP connection due to PPP resync TCP connection closed; network unavailable; application buffer not valid as part of address space; no empty buffer available for read; Or end of received file marker sendto () Sends the specified number of bytes Invalid socket descriptor specified; address family not specified; no empty buffer available for writing; network unavailable; application buffer not valid part of address space; specified option not supported; Or destination address requested recvfrom () reads a specified number of bytes Invalid socket descriptor specified; address family not supported; no empty buffer available for writing; network unavailable; application buffer not valid part of address space; Or specified option not supported

In another embodiment, the machine can read a machine readable medium containing encoded information, such as encoded software code, which triggers the processing described above to allow the mobile station application to identify the designated event. The machine readable medium may receive encoded information from a storage device or communication network, such as a memory or a storage disk. Machine-readable media can also be programmed with encoded information when the media is produced. The machine may include at least one of the application 260, the communication protocol stack 280, and the API 270, while the machine readable medium includes a memory, such as a storage disk.

Although the present invention has been described in particular embodiments, it is not limited thereto, and is only limited by the scope of the claims and their identity.

Claims (24)

As a way of notifying the mobile station application of the specified event: Communicating between a mobile station communication protocol stack and a communication network; Communicating via a mobile station application interface between the mobile station communication protocol stack and the mobile station application; Detecting the designated event by at least one of the mobile station communication protocol stack and a mobile station application interface; And Invoking the mobile station application to notify the designated event. 2. The method of claim 1, further comprising invoking an asynchronous notification. 2. The method of claim 1 wherein the notification call comprises a callback function. 2. The method of claim 1, further comprising calling, by a signal, a specified event to the mobile station application. 2. The method of claim 1, further comprising invoking, by a message, a specified event to a mobile station application. 2. The method of claim 1, further comprising invoking, by interrupt, a specified event to the mobile station application. 4. The method of claim 3, wherein the callback function is called for a network subsystem event. 4. The method of claim 3, wherein the callback function is called for a socket event. A device for notifying a mobile station application of a specified event: A mobile station communication protocol stack for communicating with a communication network; And A mobile station application interface for facilitating communication between the mobile station communication protocol stack and the mobile station application; At least one of the mobile station communication protocol stack and a mobile station application interface detects the designated event and the notification of the designated event for the mobile station is invoked 10. The apparatus of claim 9, wherein the notification comprises an asynchronous notification. 10. The apparatus of claim 9, wherein the call notification comprises a callback function. 10. The apparatus of claim 9, wherein the notification is communicated by a signal. 10. The apparatus of claim 9, wherein the notification is communicated by a message. 10. The apparatus of claim 9, wherein the notification is communicated by interrupt. 12. The apparatus of claim 11, wherein the callback function is called for a network subsystem event. 12. The apparatus of claim 11, wherein the callback function is called for a socket event. A machine readable medium comprising encoded information, When the encoded information is read by the machine: Communicates between a mobile station communication protocol stack and a communication network; Communicate via a mobile station application interface between the mobile station communication protocol stack and a mobile station application; Detect the designated event by at least one of the mobile station communication protocol stack and a mobile station application interface; And Invoking the mobile station application to notify the designated event. 18. The machine readable medium of claim 17, further comprising invoking an asynchronous notification. 18. The machine readable medium of claim 17 wherein the call notification comprises a callback function. 18. The machine readable medium of claim 17, further comprising notifying the mobile station application by signal of the designated event. 18. The machine readable medium of claim 17, further comprising notifying the mobile station application by message of the designated event. 18. The machine-readable medium of claim 17, further comprising notifying the mobile station application of the designated event by an interrupt. 20. The machine readable medium of claim 19, wherein the callback function is called for a network subsystem event. 20. The machine readable medium of claim 19, wherein the callback function is called for a socket event.