JP2003530021A - Method and apparatus for notifying a mobile station application of a specified event - Google Patents

Abstract

(57) 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 communication between a mobile station communication protocol stack and a mobile station application communicating with a communication network. The mobile station communication protocol stack or mobile station application interface detects the specified event and implements notification of the specified event to the mobile station application.

Description

Detailed Description of the Invention

[0001]

TECHNICAL FIELD OF THE INVENTION

Background 1. FIELD OF THE INVENTION The present invention relates generally to the field of wireless communications. More particularly, the present invention relates to a novel method and apparatus for notifying mobile station applications of specified events in a wireless communication system.

2. Description of Related Techniques A. Wireless Communications Recent innovations in wireless communications and computer-related engineering, as well as an unprecedented increase in Internet subscribers, have led to mobile computing.
paved the way to ng). In fact, the popularity of mobile computing is on the current Internet infrastructure in order to provide greater support to mobile users.
Has brought greater demand. The source of vitality for this infrastructure is the local and wide area networks (local and wide area).
packets between networks (LAN and WAN) (datagram (da
, packet-oriented Internet Protocol (IP), which provides a variety of services. IP protocol is 1
"Internet Protocol US Department of Defense Advanced Research Projects Office, dated September 981 (
Request for comment, entitled "DARPA) Internet Program Protocol Specification",
No. 791 (RFC791).

The IP protocol is a network layer protocol that confines data in IP packets for transmission. The addressing and routing of information is fixed in the header of the packet. The IP header contains, for example, a 32-bit address that identifies the sending and receiving hosts. These addresses are used by an intermediate router to select a path through the network for packets destined for their final destination with the intended addresses. Thus, the IP protocol allows packets originating at any internet node in the world to be routed to any other internet node in the world. On the other hand, Transmission Control Protocol (TCP) or User Datagram Protocol (
Transport layer, including either UDP), is used to address specific applications.

The current trend is to work with a wireless communication device such as a cellular or portable telephone to access the Internet, in cooperation with a laptop or palmt.
op) In the direction of mobile users using mobile computers such as computers. That is, just as users traditionally use "wired" communication devices to connect their computers to terrestrial networks, mobile users:
To connect their mobile terminals to such networks, wireless communication devices commonly referred to as "mobile stations" (MS) will be used. As used herein, mobile station, or MS, will refer to any subscriber station in the public wireless network.

In FIG. 1 (prior art), MS 110 is a base station / mobile switching center (BS / MSC).
1 schematically illustrates a high level block diagram of a wireless data communication system in communication with an interworking function (IWF) 108 via 106. The IWF 108 serves as an access point to the Internet. The IWF 108 can be a traditional radio base station, as known in the art, coupled to and often provided with the BS / MSC 106. Another standard protocol for addressing wireless data communication systems is the Third Generation Partnership Project 2 ("3GPP2"), published in December 1999, entitled "Wireless IP Network Standards". 3G
Wireless IP network standards include, for example, a packet data serving node (“PDSN”) that functions like the IWF 108.

There are various protocols that address data communication between the MS 110 and the IWF 108. For example, published in July 1993, entitled "Mobile Station-Base Station Compatibility Criteria for Dual Mode Wideband Spread Spectrum Cellular Systems", Interim Telecommunications Industry Association (TIA) / Electronic Industries Association (EIA) Provisional. Standard IS-95 provides, in general, a standard for wideband spread spectrum wireless communication systems. Furthermore,
Standard TIA / published February 1998, entitled "Data Service Options for Broadband Spread Spectrum Systems: Packet Data Services".
EIA IS-707.5 defines requirements for support of packet data transmission capability on TIA / EIA IS-95 systems, and BS / MSC10
6 specifies a packet data bearer service that may be used for communication between the MS 110 and the IWF 108 over 6. In addition, both are 1999
Published in March, 2013, entitled "Data Service Options for Spread Spectrum Systems: Packet Data Service", TIA / EIA IS-707.
-A. 5 Standards, and TIA / EIA IS-7 entitled "Data Service Options for Spread Spectrum Systems: High Speed Packet Data Services"
07-A. The 9 standard also defines requirements for packet data transmission support on TIA / EIA IS-95 systems. Furthermore, MS110 and IWF10
Another standard protocol for addressing communications to and from H.8 is TIA / EIA IS-2000, published in July 1999, entitled "Introduction to the CDMA2000 Standard for Spread Spectrum Systems."

IS-707.5 is between the MS 110 and the BS / MSC 106 (Um interface) and between the BS / MSC 106 and the IWF 108 (L interface).
Introduce a communication protocol option model to. For example, relay model (Rel
ay Model) is a Point-to-Point Protocol (PPP) link with M
It represents the situation existing on the Um interface between S110 and IWF 108.
The PPP protocol is described in detail in Request for Comment, No. 1661 (RFC1661), entitled "Point-to-Point Protocol (PPP)".

FIG. 2 (Prior Art) is a diagram of a protocol stack in each entity of the IS-707.5 relay model. At the far left of the figure,
There is a communication protocol stack, shown in traditional vertical format, showing the protocol layers operating on the MS 110. The MS 110 protocol stack is shown diagrammatically as being logically connected to the BS / MSC 106 protocol stack via the Um interface. The BS / MSC106 protocol stack is
In turn, it is shown diagrammatically as being logically connected to the IWF 108 protocol stack via the L interface.

The operations depicted in FIG. 2 are as follows: A higher layer protocol 200 entity, such as an application program running on MS 110, needs to send data over the Internet. Typical applications are web browser programs (eg, Netscape Navigator ^™ ), Microsoft Internet Explorer ™ (Micros).
of the Internet Explorer ^™ )). The web browser is a universal resource locator (Universal Resource Locator (Universal), such as the hyperlink " http: //www.Qu alcomm.com ".
Request a rrsal Resource Locator (URL). The Domain Name System (DNM) protocol is used even in the upper layer protocol 200, and the original host name www. Qulcom m. com is translated into a 32-bit numeric IP address by using domain name resolution to translate the name into an address on the Internet. Hypertext Transfer Protocol (Hypertext
Transfer Protocol (HTTP) is an upper layer protocol 20.
Constructs a GET message for the requested URL that is also zero, and TC
Specifies that P sends a message and is used for HTTP action. Transport layer 202 uses port 80, which is well known in the art, so that the destination port routes HTTP effects to the application.

The TCP protocol is a transport layer protocol 202 that opens a connection to an IP address specified by DNS and that is application level H
Transmit a TTP GET message. The TCP protocol specifies that the IP protocol be used for message transport. I
The P protocol is the network layer protocol 204 and transmits a TCP packet to a designated IP address. PPP is a link layer protocol 206 that encodes IP packets and transmits IP packets (thems) to a relay layer protocol 208. An example of the relay layer protocol 208 is shown diagrammatically in "Interface between Data Terminal Equipment and Data Circuit Termination Equipment Using Continuous Binary Data Exchange", published October October 1997. TIA /
It may be the EIA-232F standard. It is understood that other criteria or protocols known to those of ordinary skill in the art may be used to define the transmission across the layers. For example, another applicable standard is the "UNIVERSAL SERIAL BUS" published in September 1998.
(USB) specification, revised 1.1 ", and" BLUETOOTH specification, revised 1.0A abstract, "published in July 1999. Finally, the relay layer protocol 208 is , BS / via Um interface
The PPP packet is transmitted by the radio link protocol (RL) for transmission to the MSC 106.
P) 210 and then IS-95 protocol 212. RLP Protocol 210 is published in February 1998, entitled "Data Service Options for Wideband Spread Spectrum Systems: Radio Link Protocol," IS-7.
The IS-95 protocol, defined in the 07.2 standard, is based on the previously identified IS-
95 standards.

The complementary relay layer protocol 220 on the BS / MSC 106 is IS-95 Layer 2
18. Then, the PPP packet is received through the RLP layer 216 and the Um interface. The relay layer protocol 220 uses the IW via the L interface.
Hand the PPP packet to the relay layer protocol 228 on F108. IWF10
8 PPP protocol link layer 226 receives a plurality of PPP packets from relay layer protocol 228 and terminates the PPP connection between MS 110 and IWF 108. The packet is www. Qualcomm. For testing the IP packet header for the final routing is c om, handed from PPP layer 226 to the IP layer 224 on the IWF 108.

The final destination of the IP packet generated by the MS 110 is the IWF 108.
Assuming not, the packet is forwarded through network layer protocol 224 and link layer protocol 225 to the next router on the Internet (not shown). In this way, the IP packet from the MS 110 is BS / M
Through the SC 106 and the IWF 108, according to the IS-707.5 standard relay model, the IP packet (their) in the Internet is transmitted toward the intended final destination.

Before MS 110 packets arrive at their destination, a data link connection must first be established. As specified in RFC1661, this is done at each end of a point-to-point link (i.e., PPP protocols 206 and 226) to establish, form, and test a data link connection. LCP) request to send a packet first. Link is L
After being established by the CP, the PPP protocol 206 can then send Network Control Protocol (NCP) packets to form the network layer protocols 204 and 224. NCP for IP in a PPP link is the IP Control Protocol (IPCP). IPCP was published in May 1992 in the "PPP Internet Protocol Control Protocol (IPC
P) ", Request for Comment, No. 1332 (RFC1332). However, an authentication stage may be required prior to IPCP negotiation. Each network layer protocol is formed. After that, packets from each network layer protocol can be sent over the links between the network layer protocols.

B. Application Program Interface If not all, most of the processing that supports the communication protocol stack on MS 110 is performed by the application program. Overall,
Traditional data networks use application program interfaces (APIs) to allow application programs running on one computer to communicate with application programs running on another computer. The API is a "socket" that protects the implementing application from differences in the underlying network protocols.
t) ". To achieve inter-networked communication, the API may, for example, cause an application to open a socket, send data to the network, receive data from the network, and receive the socket from the network. A common network programming interface is the Berkeley Systems operating under the Unix ^™ operating system.
Drovement (BSD) socket interface, and the Windows ( ^TM ) Sockets Interface (Windows ( ^TM ) Socket) operating under the Windows (TM) (Windows ( ^TM )) operating system.
ts Interface) (Winsock ^™ )
including.

[0015]

[Problems to be Solved by the Invention]

Since neither BSD sockets nor Winsock ™ support communication protocol stacks on wireless MS 110 (see FIG. 2), novel APIs supporting such stacks are needed. In particular, what is needed is a new method and apparatus for informing MS 110 applications of specified events in a wireless communication system.

[0016]

[Means for Solving the Problems]

SUMMARY OF THE INVENTION The present invention addresses the previously identified needs by providing a method and apparatus for informing mobile station applications of specified events in a wireless communication system. In one implementation, the invention includes an application program interface (API) that facilitates communication between a mobile station application and a mobile station communication protocol stack that communicates with a communication network. The mobile station communication protocol stack or mobile station application interface detects the specified event and implements notification of the specified event to the mobile station application.

[0017]

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the invention may be implemented in various implementations, including software, firmware, and / or hardware. Therefore, the operation and operation of the present invention will be described without making any specific reference to software codes or hardware components, and those skilled in the art can, based on the description therein, assign a specified event to a mobile station application. It is understood that software and / or hardware can be designed to implement the present invention.

FIG. 3 illustrates an application 260, a communication protocol stack 280, and an MS.
The API 270 in 110 is shown. Application 260 and communication protocol stack 280 (ie, protocol layers 202, 204, 206, 208, 210).
, 212) communicate through function calls provided by API 270. In other words, API 270 allows application 260 and communication protocol stack 280 to operate on different processors and operating systems without compromising functionality. Those skilled in the art will appreciate that various names for implemented functions are possible without departing from the scope of the invention.

It should be noted that the communication protocol stack 280 includes multiple send and receive queues that store data. The output function reads the data from the memory of the application 260 in order to store the data in one of the transmission queues of the communication protocol stack 280. The input function reads the data from one of the receive queues of the communication protocol stack 280 to store the data in the memory of the application 260.

To illustrate the operation diagrammatically, MS 110 receives an IP packet. MS1
The communication protocol stack 280 of 10 releases the IP packet and hands the IP packet to the transport layer 202 (see FIG. 3). The field in the IP packet header indicates a transport which may be 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 can then be transmitted to the application 260.

In certain situations, it may be desirable to work with packets that pass through the various layers of protocol stack 280 to reduce latency effects. Such packets include raw packetized data, such as raw IP packets lacking destination information (ie, destination port number). As such, the destination application may not be determined from the raw IP packet. In such a situation, the communication protocol stack 280 may, for example,
Raw IP packets received can be transmitted to all sockets registered to support the IP protocol. This causes the toll load data to be transmitted to the destination application. An Internet Controlled Messaging Protocol (ICMP) analysis engine that responds to IP packets can also receive raw packetized data. The well-known ICMP parsing engine is defined in RFC 792, entitled "Internet Control Message Protocol". Prior to the communication protocol stack 280 handing a packet onto the stack to the application 260, which reduces the amount of release made by the application 260, it is this description that the communication protocol stack 280 processes received packets, for example. Should be clear from.

Conversely, the application 260 was raw packetized via the Um interface by using sockets to facilitate communication between the communication protocol stack 280 and the application 260. Data can be transmitted. Furthermore, the application 260 can transmit raw packetized data via the Um interface. In order, the communication protocol stack 28
0 confines packetized or raw packetized data in, for example, IP packets and transmits IP packets (them) via the Um interface. In this example, the communication protocol stack 280 provides the IP header and checksum to generate the IP packet. On the other hand, for ICMP, the specified protocol type can be duplicated in the IP header.

As previously mentioned, the application 260 may use the protocol layers 202, 204.
, 206, 208, 210, 212 and an application 260
Creates a socket for data communication between and with which reduces latency inherent when using the communication protocol stack 280. That is, the application 260
Creates a socket that passes through transport layer 202, network layer 204, and link layer 206, and thus allows application 260 to RLP.
Pay load data may be transmitted to layer 210 or pay load data may be received from RLP layer 210. Moreover, the application 260 is the application 26.
0 to transmit payload data to IS-95 layer 212, or IS-95 layer 21
It is possible to create a socket that receives load weight data from 2.

In one embodiment, the application 260 is responsible for opening the communication protocol stack 280 and for application identification.
function) open_netl to assign the
Call ib (). Application identification allows a wide variety of applications to communicate with communication protocol stack 280 (ie, do a lot of work).
. As part of the call to the function open_netlib (), for example, the application 260 specifies a pointer to the network callback function and to the socket callback function. The network callback function may include traffic channel (ie Um) and / or link layer (
That is, a specified event of the network subsystem has occurred (or enabled) such as reading from, writing to, and closing of PPP 206).
At any time, this is done to inform the application 260. The socket callback function reads from the transport layer (i.e., TCP), writes to the layer, and closes the layer, resulting in a specified event of the socket (
Whenever possible), it is implemented to inform the application 260. It should be obvious to a person skilled in the art that the communication network comprises 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 including traffic channels and link layers. This is an application-wide call that does not depend on individual sockets. However, it requires application identification. Upon establishment or failure of the network subsystem connection, a network callback function is implemented to provide notification of specified events. For example, if the traffic channel is not established, the network subsystem will fail. In addition, the network subsystem characteristics are functional net.
It may be set using a call to _ioctl (). This call is
For example, the data rate of the socket may be specified.

Once the network subsystem connection is established, the socket (or sockets) is created and initialized through a call to the functional socket (). However, before the socket function can be used, a call to the function socket () can return a socket descriptor. Therefore, the application 260 receives the asynchronous notification by
The function async_select () for registering the specified event can be called. This registration is a socket descriptor and bit mask of the specified event requiring notification (ie, OR'ed together).
Multiple events) may be performed by application 260 as part of a function call. For example, a specified event has occurred (i.e., allowed to do it) and it has a communication protocol stack 280 or API2.
If detected by 70, the socket callback function is implemented to provide asynchronous notification. The callback function may notify the application 260 of a specified event by using a remote processing call (RPC), or a signal including a message via a hardware or software interruption, a message.

Once the application 260 has been notified of the specified event, it may then use the function getnext to determine the specified event to serve.
Vent () can be called. This function returns a mask of the specified event that has occurred for the specified socket descriptor. Moreover, it clears the bit in the mask of the specified event that occurred. Thus, the application 260 may no longer receive notification of the disabled specified event. The application 260 must re-register these specified events (ie, allow it to happen again) through subsequent calls to the function async_select ().

In addition, the application 260 may change the registered and specified event by clearing the corresponding bit in the specified event bit mask. If the bit has already been cleared in the bitmask, then the request is simply ignored. That is, the event notification may be, for example, the function async_de.
It can be disabled based on each event through a call to select ().

4 and 5 are flowcharts for detecting a designated event. Figure 4
For example, as shown in FIG.
At, wait for application 260 to register for a particular event. After the specified event has been registered, the communication protocol stack 280 polls in memory at block 402. At block 404, the specified event can be detected based on the registered information at block 402. At block 406, for example, when the memory of the communication protocol stack 280 (ie, the send queue) is available to accept a sufficient amount of data,
Write events are detected. Data can be transmitted from application 260. The inspected information in block 404 is not satisfactory (ie,
If the specified event has not occurred), then the communication protocol stack 28
0 continues to register memory, as in block 402.

In FIG. 5, the communication protocol stack 280 waits for the application 260 to register the specified event, as shown in block 500. During this time, the discontinuation notice may be disabled. As such, the discontinuation notification cannot be triggered or activated. After the designated event has been registered, as in block 500, at block 502 an interruption notification may be triggered based on the occurrence of the designated event. A read event occurs, for example, when data is written to the memory of the communication protocol stack 280 (ie, the receive queue). Thus, at block 504,
The read event is detected by the communication protocol stack 280 when it receives the suspend notification triggered due to the occurrence of the event. The data stored in the memory of the communication protocol stack 280 may come from the communication network. Furthermore, for read events, the stored data is
60 can be transmitted.

Finally, a close event (close e) occurs when the socket is available for reuse, as the data link connection is terminated, eg at the transport layer.
Vent) is detected.

The following examples of asynchronous connections (see FIG. 6) and asynchronous inputs (see FIG. 7) are provided to illustrate schematically the use of asynchronous event notification.

Referring to FIG. 6, both communication protocol stacks 280 are entered and the callback function is specified through a call to the function open_netlib (). A call (A) to the function ppopen () initiates a network subsystem connection (B). After the network subsystem connection is established, a callback function is implemented to report the availability of the network subsystem (C). Assuming the socket has been opened and allocated, the function connect (
Call to ()) initiates a TCP connection (E). In addition, the application 260 may use the function asy to register a specified event for receiving notifications.
Call nc_select () (F). In this example, the specified event of interest is a write event that occurs concurrently with establishing the connection.

At connection k establishment, if the specified event is registered in the mask, the callback function is implemented. If so, then a callback function is implemented to provide asynchronous notification (G). Once the application 260 is notified, it calls the function getnextevent () (H) to determine which specified event (I) occurred. In addition, this call clears the event (ie, write event) bit in mask (J). The application 260 must re-register for notification of subsequent specified events through a call to the function async_select ().

In FIG. 7, a description of asynchronous socket read is provided. To start reading, the application 260 makes a call to the function read () (
A). Given the lack of data to read, application 260 calls the function async_select () to register an event to receive the notification (ie, set the corresponding bit in the mask) (B
). In this example, the specified event of interest is the application 260.
Is a read event that occurs when there is data to read by.

When accumulating data in the receive queue, a callback function is implemented if a read event is specified in the mask. If so,
The callback function is then implemented to provide asynchronous notification (C).
Once the application 260 is notified, it calls the function getnextevent () to determine which event (E) has occurred (E).
D). In addition, this call clears the event bit in mask (F). The application 260 must allow notification of subsequent events again through a call to the function async_select (). Finally, the application 260 makes a call (G) to the function read () to retrieve the data stored in the receive queue.

8-10, a state machine of an embodiment of the present invention.
Are shown diagrammatically. 8-9, the communication protocol stack 280
Is opened, and a network subsystem connection (ie, traffic channel, and link layer, if needed-if raw socket can pass through the network subsystem) is established. Is assumed. Those skilled in the art will appreciate that various names for the conditions are possible without departing from the scope of the invention.

State machines that can transition between states asynchronously include read, write,
And control (ie, enable and disable) specified events, such as closing. The specified event may be disabled at the beginning of the action and may support the application 260 in a predetermined state to identify the state of the MS 110.

Moreover, API 270 reports specific (ie, simply uncommon) specified status messages to application 260 based on the status of API 270 and the capabilities of the type called by application 260. The designated status message can reflect the status of the underlying communication network.
The status message is reported to application 260 as the subject of the function call, for example.

In FIG. 8, for example, a state diagram for the TCP socket of API 270 is schematically shown. An uninitialized socket is "null"
Begin at state 800. Sockets do not “exist” because they have not been distributed so far. The socket returns the socket descriptor for using the socket related functions, and the function socket ()
Can be created and initialized through a call to. Function socket
After the call to (), the state machine transitions to the "initialize" state 805.

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

In the open state 810, (1) a network subsystem failure occurs, (
Whenever there is a 2) TCP connection establishment failure, or (3) a changed IP address, the state machine transitions to the “closed” state 815. Moreover, after a call to the function close () that terminates the TCP connection, the state machine transitions the socket to the "close" state 820 while the termination procedure is being initiated. Finally, the state machine transitions to the "open" state 825 as soon as the TCP connection is established.

In the open state 825, the socket is open for reading and writing. In particular, write events are enabled immediately, while read events are enabled based on whether data is stored in the memory of the communication protocol stack 280. (1) Network subsystem failure occurs, (2) TCP connection establishment failure (error), (3) Attempt to terminate TCP connection (eg, TCP reset, TCP abort, or TCP initiated by network server). Close) and (4) IP address change, the state machine transitions to the “closed” state 815. Function c
The application that initiated the TCP connection termination, such as by a call to lose (), transitions the state machine to the closed state 820.

In the closed state 815, read, write, and close events are all asserted. After a call to the function close () that closes the TCP connection, the state machine releases the socket and makes it available for reuse.
Move the socket to the zero state 800.

In the closed state 820, (1) a network subsystem failure occurs,
(2) Attempt to terminate TCP connection (eg T initiated by network server)
CP reset or TCP close), (3) timer expiration, and (4) IP
Whenever there is a change of address, the state machine transitions to the "wait for close" state 830.

To protect against delays in terminating TCP connections, API 270 uses TCP
It provides the necessary means for the timer to be activated at the beginning of the termination of the connection. As you can see
The expiration of the timer causes the state machine to transition to state 830, waiting to close.

In the wait to close state 830, a call to the function close () terminates the TCP connection and transitions the state machine to the zero state 800. The close event is asserted in this state 830.

Tables 1-3 graphically show the specified status messages supported by the API 270. In the zero state (not shown in Tables 1-3), a descriptive, designated state message "No additional resources available" can be reported to application 260. .

[0049]

[Table 1]

[Table 2]

[Table 3] As an example, FIG. 9 schematically shows a state diagram for a UDP socket of API 270. Uninitialized sockets start with a "zero" state 900. As previously noted with respect to the zero state 800, the socket was "unassigned", so "
Does not exist. A socket can be created and initialized through a call to the function socket () which returns a socket descriptor for use with socket related functions. ), The state machine transitions to the "open" state 905.

In the open state 905, the socket is open for reading and writing. In particular, while the read event is enabled based on whether data is stored in the memory of the communication protocol stack 280,
The write event is made available immediately. The state machine transitions to the “closed” state 910 whenever a network subsystem failure occurs.
An application that initiates a UDP connection close, such as by a call to the function close (), transitions the state machine to the zero state 900. Closed state 910
At, read, write, and close events are all enabled. U
After the call to the function close () that terminates the DP connection, the state machine transitions the socket to the zero state 900, which releases the socket and makes it available for reuse.

Tables 4-6 schematically show the specified status messages supported by API 270. In the zero state (not shown in Tables 4-6), the designated status message "No additional resources available", as described above, is reported to the application 260. be able to.

[0052]

[Table 4]

[Table 5]

[Table 6] FIG. 10 illustrates a traffic channel (ie, Um) and a link layer (ie, PP).
P206) is a state diagram for controlling a network subsystem. A call to the function open_netlib () opens the network subsystem and initializes the socket to the "closed" state 1000. Function ppp
A call to open () moves the socket to the "open" state 1005,
Initiate a network subsystem connection. Moreover, a call to MS 110 by an incoming PPP call causes the socket to transition to open state 1005. In both cases, upon successful negotiation, MS 110 attempts to synchronize and establish both RLP and PPP across the traffic channel.

In the open state 1005, the socket transitions to the “open” state 1010 concurrently with the network subsystem connection being established. On the other hand, if the network subsystem connection is not established, the socket is in closed state 1.
Return to 000. In the open state 1010, the callback function is implemented to make available specified events such as read, write, and close to the application 1
Identify to 060. At this time, the MS 110 can communicate through the traffic channel. However, the socket implementing the callback function transitions to the closed state 1000 whenever a network subsystem error occurs. As by a call to the function close (),
The application that started the network subsystem connection termination is "Close"
Transition the socket to 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, a callback function is performed to identify to the application 260 the specified event being made available.

Table 7 graphically illustrates designated status messages that correspond to a particular function call and are supported by API 270.

[0056]

[Table 7-1]

[0057]

[Table 7-2]

[0058]

[Table 7-3]

[0059]

[Table 7-4]

[0060]

[Table 7-5] In another embodiment, the machine is such as a software code that causes the mobile station application to perform the previously described process of notifying the specified event.
A machine-readable medium containing the encoded information can be read. The machine-readable medium may accept encoded information from a storage device, such as a memory or storage disk, or from a communication network. Moreover, a machine-readable medium may be programmed with encoded information when the medium is manufactured. The machine has an application 260, a communication protocol stack 280, and an API 270.
Of at least one, while the machine-readable medium may comprise a memory or a storage disk.

Although the present invention has been shown with respect to particular embodiments, it should not be considered so limited. To be precise, the invention is limited only by the scope of the appended claims and their equivalents.

[Brief description of drawings]

FIG. 1 is a high level block diagram of a wireless communication system in which a mobile station connects to the Internet (prior art).

FIG. 2 schematically illustrates the protocol stack in each entity of the TIA / EIA IS-707.5 relay model (prior art).

[Figure 3]   FIG. 3 schematically depicts features of an embodiment of the invention.

[Figure 4]   FIG. 4 is a flowchart for detecting the designated event.

[Figure 5]   FIG. 5 is a flowchart for detecting the designated event.

[Figure 6]   FIG. 6 is a block diagram depicting an asynchronous connection.

[Figure 7]   FIG. 7 is a block diagram depicting an asynchronous socket input.

[Figure 8]   FIG. 8 is a state diagram of an embodiment of the present invention.

[Figure 9]   FIG. 9 is a state diagram of an embodiment of the present invention.

[Figure 10]   FIG. 10 is a state diagram of the embodiment of the present invention.

─────────────────────────────────────────────────── ─── Continued front page    (81) Designated countries EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, I T, LU, MC, NL, PT, SE, TR), OA (BF , BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, G M, KE, LS, MW, MZ, SD, SL, SZ, TZ , UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, B Z, CA, CH, CN, CR, CU, CZ, DE, DK , DM, DZ, EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, J P, KE, KG, KP, KR, KZ, LC, LK, LR , LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, NO, NZ, PL, PT, R O, RU, SD, SE, SG, SI, SK, SL, TJ , TM, TR, TT, TZ, UA, UG, UZ, VN, YU, ZA, ZW (72) Inventor Gilkey, Harold             California, United States             92122 San Diego, Nobel Dora             Eve 3717, apartment 1432 F-term (reference) 5B089 GB01 KG01                 5K030 HA08 HC01 HC14 HD06 JL01                 5K067 BB04 BB21 DD11 EE02 EE10                       EE16

Claims (24)

[Claims] 1. A method for notifying a mobile station application of a specified event, comprising the following steps: communicating between a mobile station communication protocol stack and a communication network; a mobile station communication protocol stack through a mobile station application interface. A specified event by at least one of the mobile station communication protocol stack and the mobile station application interface; and performing notification of the specified event to the mobile station application. . 2. The method of claim 1, further comprising implementing asynchronous notification. 3. The method of claim 1, wherein the implementing notification comprises a callback function. 4. The method of claim 1, further comprising notifying the mobile station application of the event specified by the signal. 5. The method of claim 1, further comprising notifying the mobile station application of the event specified by the message. 6. The method of claim 1, further comprising notifying the mobile station application of the event specified by the interruption. 7. The method of claim 3, wherein the callback function is implemented for a network subsystem event. 8. The method of claim 3, wherein the callback function is implemented for socket events. 9. An apparatus for notifying a mobile station application of a specified event, comprising: a mobile station communication protocol stack for communicating with a communication network; and between the mobile station communication protocol stack and the mobile station application. A mobile station application interface for facilitating communication; wherein at least one of a mobile station communication protocol stack and a mobile station application interface is adapted to detect a specified event; and to a mobile station application Notification of the specified event is performed. 10. The apparatus of claim 9, wherein the notification comprises an asynchronous notification. 11. The device of claim 9, wherein the notification comprises a callback function. 12. The apparatus of claim 9, wherein the notification is signaled. 13. The apparatus of claim 9, wherein the notification is conveyed by a message. 14. The apparatus of claim 9, wherein the notification is conveyed by interruption. 15. The apparatus of claim 11, wherein the callback function is implemented for a network subsystem event. 16. The apparatus of claim 11, wherein the callback function is implemented for socket events. 17. A machine-readable medium comprising encoded information, which when read by a machine causes the following processing: communicating between a mobile station communication protocol stack and a communication network; a mobile station application interface. Communication between the mobile station communication protocol stack and the mobile station application through the mobile station; detecting a specified event by at least one of the mobile station communication protocol stack and the mobile station application interface; To notify the event. 18. The machine-readable medium of claim 17, further comprising implementing asynchronous notification. 19. The implementing notification comprises a callback function.
7. Machine-readable medium. 20. The machine-readable medium of claim 17, further comprising signaling a designated event to a mobile station application. 21. The machine-readable medium of claim 17, further comprising notifying the mobile station application of the event specified by the message. 22. The machine-readable medium of claim 17, further comprising notifying a mobile station application of a specified event upon interruption. 23. The machine-readable medium of claim 19, wherein the callback function is implemented for a network subsystem event. 24. The machine-readable medium of claim 19, wherein the callback function is implemented for socket events.