CA2706874A1 - Method and apparatus for detecting specified events in a mobile station - Google Patents
Method and apparatus for detecting specified events in a mobile station Download PDFInfo
- Publication number
- CA2706874A1 CA2706874A1 CA2706874A CA2706874A CA2706874A1 CA 2706874 A1 CA2706874 A1 CA 2706874A1 CA 2706874 A CA2706874 A CA 2706874A CA 2706874 A CA2706874 A CA 2706874A CA 2706874 A1 CA2706874 A1 CA 2706874A1
- Authority
- CA
- Canada
- Prior art keywords
- mobile station
- specified event
- application
- protocol stack
- specified
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Communication Control (AREA)
- Telephonic Communication Services (AREA)
- Computer And Data Communications (AREA)
Abstract
The present invention discloses a method and apparatus for detecting 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 polls a memory when the mobile station application registers a specified event. Based on the polling, the mobile station communication protocol stack then detects the specified event. In another implementation of the present invention, the mobile station communication protocol stack detects the specified event by an interrupt notice, which is triggered when the specified event occurs.
Description
METHOD AND APPARATUS FOR DETECTING SPECIFIED
EVENTS IN A MOBILE STATION
This application is a divisional of Canadian Patent Application No. 2,404,146 filed March 29, 2001.
BACKGROUND
1. Field of the Invention This invention generally relates to the field of wireless communications.
More particularly, the present invention relates to a novel method and apparatus for detecting a specified event in a wireless communication system.
EVENTS IN A MOBILE STATION
This application is a divisional of Canadian Patent Application No. 2,404,146 filed March 29, 2001.
BACKGROUND
1. Field of the Invention This invention generally relates to the field of wireless communications.
More particularly, the present invention relates to a novel method and apparatus for detecting a specified event in a wireless communication system.
2. Description of 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. In fact, the popularity of mobile computing has placed greater demands on the current Internet infrastructure to provide mobile users with more support. The life blood of this infrastructure is the packet-oriented Internet Protocol (IP) which provides various services, including the addressing and routing of packets (datagrams) between local and wide area networks (LANs and WANs). IP protocol is defined in Request For Comment 791 (RFC 791) entitled, "INTERNET PROTOCOL DARPA
INTERNET PROGRAM PROTOCOL SPECIFICATION," dated September 1981.
The IP protocol is a network layer protocol that encapsulates data into IP
packets. for transmission. Addressing and routing information is affixed to the header of the packet. 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 towards its ultimate destination at the intended address. 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, a transport layer, which comprises either a Transmission Control Protocol (TCP) or a User Datagram Protocol (UDP), is used to address to particular applications.
The current trend is for mobile users to use mobile computers, such as laptop or palmtop computers, in conjunction with wireless communication devices, such as cellular or portable phones, to access the Internet. That is, just as users conventionally employ "wired" communication devices to connect their computers to land-based networks, mobile users will use wireless communication devices, commonly referred to as "mobile stations" (MSs), to connect their mobile terminals, to such networks. As used herein, the mobile station or MS will refer to any subscriber station in the public wireless radio network.
FIG. 1 (Prior Art) illustrates a high-level block diagram of a wireless data communication system in which the MS 110 communicates with an Interworking Function (IWF) 108 via a Base Station/Mobile Switching Center (BS/MSC) 106. The IWF 108 serves as the access point to the Internet. IWF 108 is coupled to, and often co-located with, BS/MSC 106, which may be a conventional wireless base station as is known in the art. Another standard protocol that addresses the wireless data communication system is the 3' Generation Partnership Project 2 ("3GPP2") entitled "WIRELESS IP NETWORK
STANDARD," published in December 1999. The 3G Wireless IP Network Standard, for example, includes a Packet Data Serving Node ("PDSN"), which functions like the IWF 108.
There are various protocols that address the data communications between the MS 110 and the IWF 108. For example, Telecommunications Industry Association (TIA) /Electronics Industries Association (EIA) Interim Standard IS-95, entitled "MOBILE STATION-BASE STATION
COMPATIBILITY STANDARD FOR DUAL-MODE WIDEBAND SPREAD
SPECTRUM CELLULAR SYSTEM," published in July 1993, generally provides a standard for wideband spread spectrum wireless communication systems.
Moreover, standard TIA/EIA IS-707.5, entitled "DATA SERVICE OPTIONS
FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: PACKET DATA
SERVICES," published in February 1998, defines requirements for support of packet data transmission capability on TIA/EIA IS-95 systems and specifies packet data bearer services that may be used for communication between the MS 110 and the IWF 108 via the BS/MSC 106. Also, the TIA/EIA IS-707-A.5 standard, entitled "DATA SERVICE OPTIONS FOR SPREAD SPECTRUM
SYSTEMS: PACKET DATA SERVICES," and the TIA/EIA IS-707-A.9 standard, entitled "DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS:
HIGH-SPEED PACKET DATA SERVICES," both published in March 1999, also define requirements for packet data transmission support on TIA/EIA IS-95 systems. In addition, another standard protocol that addresses communications between the MS 110 and the IWF 108 is the TIA/EIA IS-2000, entitled "INTRODUCTION TO CDMA 2000 STANDARDS FOR SPREAD
SPECTRUM SYSTEMS," published in July 1999.
IS-707.5 introduces communication protocol option models between the MS 110 and the BS/MSC 106 (the Um interface), and between the BS/MSC 106 and the IWF 108 (the L interface). For instance, a Relay Model represents the situation 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 Request for Comments 1661 (RFC 1661), entitled "THE POINT-TO-POINT
PROTOCOL (PPP)."
FIG. 2 (Prior Art) is a diagram of the protocol stacks in each entity of the IS-707.5 Relay Model. At the far left of the figure is a communication protocol stack, shown in conventional vertical format, showing the protocol layers running on the MS 110. The MS 110 protocol stack is illustrated as being logically connected to the BS/MSC 106 protocol. stack over the Um interface.
The BS/MSC 106 protocol stack is, in turn, illustrated as being logically connected to the IWF 108 protocol stack over the L interface.
The operation depicted in Fig. 2 is as follows: an upper layer protocol 200 entity, such as an application program running on the MS 110, has a need to send data over the Internet. A representative application may be a web browser program (e.g., Netscape NavigatorTM, Microsoft Internet ExplorerTM).
The web browser requests a Universal Resource Locator (URL), such as HYPERLINK "ht!R://www.Oualcomm.com/". A Domain Name System (DNS) protocol, also in the upper layer protocol 200, translates the textual host name www.Oualcomm.com to a 32-bit numeric IP address by the use of a domain name resolution, which translates names to addresses in the Internet.
The Hypertext Transfer Protocol (HTTP), which is also an upper layer protocol 200, constructs a GET message for the requested URL, and specifies that TCP
will be used to send the message and for HTTP operations. The transport layer 202 uses port 80, which is known in the art, as the destination port to route the HTTP operations to the application.
The TCP protocol, which is a transport layer protocol 202, opens a connection to the IP address specified by DNS and transmits the application-level HTTP GET message. The TCP protocol specifies that the IP protocol will be used for message transport. The IP protocol, which is a network layer protocol 204, transmits the TCP packets to the IP address specified. The. PPP, which is a link layer protocol 206, encodes the IP packets and transmits them to the relay layer protocol 208. An example of the relay layer protocol 208 may be the illustrated TIA/EIA-232F standard, which is defined in "INTERFACE
BETWEEN DATA TERMINAL EQUIPMENT AND DATA CIRCUIT-TERMINATING EQUIPMENT EMPLOYING SERIAL BINARY DATA
INTERCHANGE," published in October 1997. It is to be understood that other standards or protocols known to artisans of ordinary skill in the art may be used to define the transmission across the layers. For example, other applicable standards may include the "UNIVERSAL SERIAL BUS (USB) SPECIFICATION, Revision 1.1," published in September 1998, and the "BLUETOOTH SPECIFICATION VERSION 1.OA CORE," published in July 1999. Last, the relay layer protocol 208 passes the PPP packets to a Radio Link Protocol (RLP) 210 and then to the IS-95 protocol 212 for transmission to the BS/MSC 106 over the Um interface. The RLP protocol 210 is defined in the IS-707.2 standard, entitled "DATA SERVICE OPTIONS FOR WIDEBAND
SPREAD SPECTRUM SYSTEMS: RADIO LINK PROTOCOL," published in February 1998, and the IS-95 protocol is defined in the IS-95 standard identified above.
A complementary relay layer protocol 220 on the BS/MSC 106 receives the PPP packets over the Um interface through a IS-95 layer 218 and then a RLP
layer 216. The relay layer protocol 220 passes them over the L interface to a relay layer protocol 228 on the IWF 108. A PPP protocol link layer 226 on the IWF 108 receives the PPP packets from the relay layer protocol 228, and terminates the PPP connection between the MS 110 and the IWF 108. The packets are passed from the PPP layer 226 to a IP layer 224 on the IWF 108 for examination of the IP packet header for final routing, which in this scenario is www.Oualcomm.com.
Assuming that the ultimate destination of the IP packets generated by the MS 110 is not the IWF 108, the packets are forwarded through the network layer protocols 224, and link layer protocols 225 to the next router (not shown) on the Internet. In this manner, IP packets from the MS 110 are communicated through the BS/MSC 106, and the IWF 108 towards their ultimate intended WO 01/76176 lPC TUS01/10139 destination in the Internet in accordance with the IS-707.5 standard relay model.
Before the MS 110 packets reach their destination, the data link connection must be established first. As specified in RFC 1661, this requires 5 each end of the point-to-point link (i.e., the PPP protocols 206 and 226) to first send PPP Link Control Protocol (LCP) packets in order to establish, configure and test the data link connection. After the link has been established by the LCP, the PPP protocol 206 may then send Network Control Protocol (NCP) packets to configure the network layer protocols 204 and 224. The NCP for EP
in PPP links is the IP Control Protocol (IPCP). IPCP is described in detail in Request for Comment 1332 (RFC 1332), entitled "THE PPP INTERNET
PROTOCOL CONTROL PROTOCOL (IPCP)," published in May 1992. Before IPCP negotiation, however, an authentication phase may be needed. After each of the network layer protocols has been configured, packets from each network layer protocol can be sent over the link between them.
B. Application Program Interface Most, if not all, of the processes supporting the communication protocol stack on the MS 110 are executed by application programs- Generally, conventional data networks employ application program interfaces (APIs) to enable application programs running on one computer to communicate with application programs running on another computer. The APIs utilize "sockets,"
which shelter the invoking applications from differences in the protocols of the underlying network. To achieve inter-networked communications, APIs comprise functions, which allow the applications, for example, to open a socket, transmit data to the network, receive data from the network, and close the socket. Common network programming interfaces include Berkeley Systems Development (BSD) sockets interface, which operates under a UnixTM operating system, and WindowsTM Sockets Interface (WinSockTM), which operates under a WindowsTM operating system.
Because neither BSD sockets nor WinSockTM supports the communication protocol stack on the wireless MS 110 (see FIG. 2), a novel API
supporting such a stack is needed. In particular, what is needed is a novel method and apparatus for detecting a specified event in a wireless communication system.
INTERNET PROGRAM PROTOCOL SPECIFICATION," dated September 1981.
The IP protocol is a network layer protocol that encapsulates data into IP
packets. for transmission. Addressing and routing information is affixed to the header of the packet. 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 towards its ultimate destination at the intended address. 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, a transport layer, which comprises either a Transmission Control Protocol (TCP) or a User Datagram Protocol (UDP), is used to address to particular applications.
The current trend is for mobile users to use mobile computers, such as laptop or palmtop computers, in conjunction with wireless communication devices, such as cellular or portable phones, to access the Internet. That is, just as users conventionally employ "wired" communication devices to connect their computers to land-based networks, mobile users will use wireless communication devices, commonly referred to as "mobile stations" (MSs), to connect their mobile terminals, to such networks. As used herein, the mobile station or MS will refer to any subscriber station in the public wireless radio network.
FIG. 1 (Prior Art) illustrates a high-level block diagram of a wireless data communication system in which the MS 110 communicates with an Interworking Function (IWF) 108 via a Base Station/Mobile Switching Center (BS/MSC) 106. The IWF 108 serves as the access point to the Internet. IWF 108 is coupled to, and often co-located with, BS/MSC 106, which may be a conventional wireless base station as is known in the art. Another standard protocol that addresses the wireless data communication system is the 3' Generation Partnership Project 2 ("3GPP2") entitled "WIRELESS IP NETWORK
STANDARD," published in December 1999. The 3G Wireless IP Network Standard, for example, includes a Packet Data Serving Node ("PDSN"), which functions like the IWF 108.
There are various protocols that address the data communications between the MS 110 and the IWF 108. For example, Telecommunications Industry Association (TIA) /Electronics Industries Association (EIA) Interim Standard IS-95, entitled "MOBILE STATION-BASE STATION
COMPATIBILITY STANDARD FOR DUAL-MODE WIDEBAND SPREAD
SPECTRUM CELLULAR SYSTEM," published in July 1993, generally provides a standard for wideband spread spectrum wireless communication systems.
Moreover, standard TIA/EIA IS-707.5, entitled "DATA SERVICE OPTIONS
FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: PACKET DATA
SERVICES," published in February 1998, defines requirements for support of packet data transmission capability on TIA/EIA IS-95 systems and specifies packet data bearer services that may be used for communication between the MS 110 and the IWF 108 via the BS/MSC 106. Also, the TIA/EIA IS-707-A.5 standard, entitled "DATA SERVICE OPTIONS FOR SPREAD SPECTRUM
SYSTEMS: PACKET DATA SERVICES," and the TIA/EIA IS-707-A.9 standard, entitled "DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS:
HIGH-SPEED PACKET DATA SERVICES," both published in March 1999, also define requirements for packet data transmission support on TIA/EIA IS-95 systems. In addition, another standard protocol that addresses communications between the MS 110 and the IWF 108 is the TIA/EIA IS-2000, entitled "INTRODUCTION TO CDMA 2000 STANDARDS FOR SPREAD
SPECTRUM SYSTEMS," published in July 1999.
IS-707.5 introduces communication protocol option models between the MS 110 and the BS/MSC 106 (the Um interface), and between the BS/MSC 106 and the IWF 108 (the L interface). For instance, a Relay Model represents the situation 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 Request for Comments 1661 (RFC 1661), entitled "THE POINT-TO-POINT
PROTOCOL (PPP)."
FIG. 2 (Prior Art) is a diagram of the protocol stacks in each entity of the IS-707.5 Relay Model. At the far left of the figure is a communication protocol stack, shown in conventional vertical format, showing the protocol layers running on the MS 110. The MS 110 protocol stack is illustrated as being logically connected to the BS/MSC 106 protocol. stack over the Um interface.
The BS/MSC 106 protocol stack is, in turn, illustrated as being logically connected to the IWF 108 protocol stack over the L interface.
The operation depicted in Fig. 2 is as follows: an upper layer protocol 200 entity, such as an application program running on the MS 110, has a need to send data over the Internet. A representative application may be a web browser program (e.g., Netscape NavigatorTM, Microsoft Internet ExplorerTM).
The web browser requests a Universal Resource Locator (URL), such as HYPERLINK "ht!R://www.Oualcomm.com/". A Domain Name System (DNS) protocol, also in the upper layer protocol 200, translates the textual host name www.Oualcomm.com to a 32-bit numeric IP address by the use of a domain name resolution, which translates names to addresses in the Internet.
The Hypertext Transfer Protocol (HTTP), which is also an upper layer protocol 200, constructs a GET message for the requested URL, and specifies that TCP
will be used to send the message and for HTTP operations. The transport layer 202 uses port 80, which is known in the art, as the destination port to route the HTTP operations to the application.
The TCP protocol, which is a transport layer protocol 202, opens a connection to the IP address specified by DNS and transmits the application-level HTTP GET message. The TCP protocol specifies that the IP protocol will be used for message transport. The IP protocol, which is a network layer protocol 204, transmits the TCP packets to the IP address specified. The. PPP, which is a link layer protocol 206, encodes the IP packets and transmits them to the relay layer protocol 208. An example of the relay layer protocol 208 may be the illustrated TIA/EIA-232F standard, which is defined in "INTERFACE
BETWEEN DATA TERMINAL EQUIPMENT AND DATA CIRCUIT-TERMINATING EQUIPMENT EMPLOYING SERIAL BINARY DATA
INTERCHANGE," published in October 1997. It is to be understood that other standards or protocols known to artisans of ordinary skill in the art may be used to define the transmission across the layers. For example, other applicable standards may include the "UNIVERSAL SERIAL BUS (USB) SPECIFICATION, Revision 1.1," published in September 1998, and the "BLUETOOTH SPECIFICATION VERSION 1.OA CORE," published in July 1999. Last, the relay layer protocol 208 passes the PPP packets to a Radio Link Protocol (RLP) 210 and then to the IS-95 protocol 212 for transmission to the BS/MSC 106 over the Um interface. The RLP protocol 210 is defined in the IS-707.2 standard, entitled "DATA SERVICE OPTIONS FOR WIDEBAND
SPREAD SPECTRUM SYSTEMS: RADIO LINK PROTOCOL," published in February 1998, and the IS-95 protocol is defined in the IS-95 standard identified above.
A complementary relay layer protocol 220 on the BS/MSC 106 receives the PPP packets over the Um interface through a IS-95 layer 218 and then a RLP
layer 216. The relay layer protocol 220 passes them over the L interface to a relay layer protocol 228 on the IWF 108. A PPP protocol link layer 226 on the IWF 108 receives the PPP packets from the relay layer protocol 228, and terminates the PPP connection between the MS 110 and the IWF 108. The packets are passed from the PPP layer 226 to a IP layer 224 on the IWF 108 for examination of the IP packet header for final routing, which in this scenario is www.Oualcomm.com.
Assuming that the ultimate destination of the IP packets generated by the MS 110 is not the IWF 108, the packets are forwarded through the network layer protocols 224, and link layer protocols 225 to the next router (not shown) on the Internet. In this manner, IP packets from the MS 110 are communicated through the BS/MSC 106, and the IWF 108 towards their ultimate intended WO 01/76176 lPC TUS01/10139 destination in the Internet in accordance with the IS-707.5 standard relay model.
Before the MS 110 packets reach their destination, the data link connection must be established first. As specified in RFC 1661, this requires 5 each end of the point-to-point link (i.e., the PPP protocols 206 and 226) to first send PPP Link Control Protocol (LCP) packets in order to establish, configure and test the data link connection. After the link has been established by the LCP, the PPP protocol 206 may then send Network Control Protocol (NCP) packets to configure the network layer protocols 204 and 224. The NCP for EP
in PPP links is the IP Control Protocol (IPCP). IPCP is described in detail in Request for Comment 1332 (RFC 1332), entitled "THE PPP INTERNET
PROTOCOL CONTROL PROTOCOL (IPCP)," published in May 1992. Before IPCP negotiation, however, an authentication phase may be needed. After each of the network layer protocols has been configured, packets from each network layer protocol can be sent over the link between them.
B. Application Program Interface Most, if not all, of the processes supporting the communication protocol stack on the MS 110 are executed by application programs- Generally, conventional data networks employ application program interfaces (APIs) to enable application programs running on one computer to communicate with application programs running on another computer. The APIs utilize "sockets,"
which shelter the invoking applications from differences in the protocols of the underlying network. To achieve inter-networked communications, APIs comprise functions, which allow the applications, for example, to open a socket, transmit data to the network, receive data from the network, and close the socket. Common network programming interfaces include Berkeley Systems Development (BSD) sockets interface, which operates under a UnixTM operating system, and WindowsTM Sockets Interface (WinSockTM), which operates under a WindowsTM operating system.
Because neither BSD sockets nor WinSockTM supports the communication protocol stack on the wireless MS 110 (see FIG. 2), a novel API
supporting such a stack is needed. In particular, what is needed is a novel method and apparatus for detecting a specified event in a wireless communication system.
SUMMARY OF THE INVENTION
The present invention addresses the need identified above by providing a method and apparatus for detecting a specified event in a wireless communication system. In one implementation, the present invention includes an application program interface (API) that facilitates communications between a mobile station communication protocol stack, which communicates with a communication network, and a mobile station application. The mobile station communication protocol stack polls a memory when the mobile station application registers a specified event. The mobile station communication protocol stack then detects the specified event based on the polling. In another implementation of the present invention, the mobile station communication protocol stack detects the specified event by an interrupt notice, which is triggered when the specified event occurs.
6a According to one aspect of the present invention, there is provided a method for a mobile station communication protocol stack to detect a specified event, the method comprising: communicating between the mobile station communication protocol stack and a communication network; communicating between the mobile station communication protocol stack and a mobile station application through a mobile station application interface; registering, by a mobile station application, the specified event; triggering an interrupt notice whenever the specified event occurs; and detecting, by the mobile station communication protocol stack, the specified event by the interrupt notice.
According to another aspect of the present invention, there is provided an apparatus for detecting a specified event, the apparatus comprising: a mobile station communication protocol stack to communicate with a communication network; and a mobile station application interface to facilitate communications between the mobile station communication protocol stack and a mobile station application, wherein the mobile station application is adapted to register the specified event, wherein an interrupt notice is adapted to trigger whenever the specified event occurs, and wherein the mobile station communication protocol stack is adapted to detect the specified event by the interrupt notice.
According to still another aspect of the present invention, there is provided a machine-readable medium comprising encoded information, which when read by a machine causes the processes of: communicating between a mobile station communication protocol stack and a communication network;
communicating between the mobile station communication protocol stack and a mobile station application through a mobile station application interface;
registering, by a mobile station application, a specified event; triggering an interrupt notice whenever the specified event occurs; and detecting, by the mobile station communication protocol stack, the specified event by the interrupt notice.
6b BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 (Prior. Art) is a high level block diagram of a wireless communication system in which a mobile station connects to the Internet.
FIG. 2 (Prior Art) schematically describes the protocol stacks in each entity of the TIA/EIA IS-707.5 Relay Model.
FIG. 3 schematically depicts features of an embodiment of the present invention-FIGS. 4 and 5 are flow charts for detecting a specified event.
FIG. 6 is a block diagram depicting an asynchronous connection.
FIG. 7 is a block diagram depicting an asynchronous socket input.
FIGS. 8-10 are state diagrams of embodiments of the present invention.
DETAILED DESCRIPTION
The embodiments of the present invention may be realized in a variety of implementations, including software, firmware, and/or hardware. Hence, the operation and behavior of the present invention will be described without specific reference to the software code or hardware components, it being understood that a person of ordinary skill in the art would be able to design software and/or hardware to implement the present invention, which detects a specified event, based on the description herein.
FIG. 3 depicts an application 260, a communication protocol stack 280, and an API 270 within a MS 110. Application 260 and communication protocol stack 280 (i.e., protocol layers 202, 204, 206, 208, 210, 212) communicate through function calls, which are provided by API 270. In other words, API 270 allows application 260 and communication protocol stack 280 to run on different processors and operating systems without compromising functionality. One skilled in the art would appreciate that various names for the invoked functions are possible without departing from the scope of the present invention.
It should be noted that communication protocol stack 280 contains a plurality of send queues and receive queues, which store data. Output functions read data from a memory of application 260 to store the data into one of the send queues of communication protocol stack 280. Input functions read data from one of the receive queues of communication protocol stack 280 to store the data into the memory of application 260.
To illustrate operation, the MS 110 receives IP packets. The communication protocol stack 280 of the MS 110 unencapsulates the IP packets, and passes them to the transport layer 202 (see FIG. 3). A field in the IP
packet header indicates the transport, which may be 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 communication protocol stack 280, which corresponds to a particular socket. The data may then be transmitted to application 260.
In certain situations, it may be desirable to operate with packets that bypass various layers of the protocol stack 280 to reduce latency effects.
Such packets include raw packetized data, such as raw IP packets, which lack destination information (i.e., destination port number). As such, the destination application may not be determined from the raw IP packets. In such situations, communication protocol stack 280 may transmit the received raw IP packets to all sockets registered to support the IP protocol, for example. This allows the payload data to be transmitted to the destination application. An Internet Control Messaging Protocol (ICMP) parsing engine, which responds to IP
packets, may also receive the raw packetized data. The well-known ICMP
parsing engine is defined in RFC 792, entitled "INTERNET CONTROL
The present invention addresses the need identified above by providing a method and apparatus for detecting a specified event in a wireless communication system. In one implementation, the present invention includes an application program interface (API) that facilitates communications between a mobile station communication protocol stack, which communicates with a communication network, and a mobile station application. The mobile station communication protocol stack polls a memory when the mobile station application registers a specified event. The mobile station communication protocol stack then detects the specified event based on the polling. In another implementation of the present invention, the mobile station communication protocol stack detects the specified event by an interrupt notice, which is triggered when the specified event occurs.
6a According to one aspect of the present invention, there is provided a method for a mobile station communication protocol stack to detect a specified event, the method comprising: communicating between the mobile station communication protocol stack and a communication network; communicating between the mobile station communication protocol stack and a mobile station application through a mobile station application interface; registering, by a mobile station application, the specified event; triggering an interrupt notice whenever the specified event occurs; and detecting, by the mobile station communication protocol stack, the specified event by the interrupt notice.
According to another aspect of the present invention, there is provided an apparatus for detecting a specified event, the apparatus comprising: a mobile station communication protocol stack to communicate with a communication network; and a mobile station application interface to facilitate communications between the mobile station communication protocol stack and a mobile station application, wherein the mobile station application is adapted to register the specified event, wherein an interrupt notice is adapted to trigger whenever the specified event occurs, and wherein the mobile station communication protocol stack is adapted to detect the specified event by the interrupt notice.
According to still another aspect of the present invention, there is provided a machine-readable medium comprising encoded information, which when read by a machine causes the processes of: communicating between a mobile station communication protocol stack and a communication network;
communicating between the mobile station communication protocol stack and a mobile station application through a mobile station application interface;
registering, by a mobile station application, a specified event; triggering an interrupt notice whenever the specified event occurs; and detecting, by the mobile station communication protocol stack, the specified event by the interrupt notice.
6b BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 (Prior. Art) is a high level block diagram of a wireless communication system in which a mobile station connects to the Internet.
FIG. 2 (Prior Art) schematically describes the protocol stacks in each entity of the TIA/EIA IS-707.5 Relay Model.
FIG. 3 schematically depicts features of an embodiment of the present invention-FIGS. 4 and 5 are flow charts for detecting a specified event.
FIG. 6 is a block diagram depicting an asynchronous connection.
FIG. 7 is a block diagram depicting an asynchronous socket input.
FIGS. 8-10 are state diagrams of embodiments of the present invention.
DETAILED DESCRIPTION
The embodiments of the present invention may be realized in a variety of implementations, including software, firmware, and/or hardware. Hence, the operation and behavior of the present invention will be described without specific reference to the software code or hardware components, it being understood that a person of ordinary skill in the art would be able to design software and/or hardware to implement the present invention, which detects a specified event, based on the description herein.
FIG. 3 depicts an application 260, a communication protocol stack 280, and an API 270 within a MS 110. Application 260 and communication protocol stack 280 (i.e., protocol layers 202, 204, 206, 208, 210, 212) communicate through function calls, which are provided by API 270. In other words, API 270 allows application 260 and communication protocol stack 280 to run on different processors and operating systems without compromising functionality. One skilled in the art would appreciate that various names for the invoked functions are possible without departing from the scope of the present invention.
It should be noted that communication protocol stack 280 contains a plurality of send queues and receive queues, which store data. Output functions read data from a memory of application 260 to store the data into one of the send queues of communication protocol stack 280. Input functions read data from one of the receive queues of communication protocol stack 280 to store the data into the memory of application 260.
To illustrate operation, the MS 110 receives IP packets. The communication protocol stack 280 of the MS 110 unencapsulates the IP packets, and passes them to the transport layer 202 (see FIG. 3). A field in the IP
packet header indicates the transport, which may be 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 communication protocol stack 280, which corresponds to a particular socket. The data may then be transmitted to application 260.
In certain situations, it may be desirable to operate with packets that bypass various layers of the protocol stack 280 to reduce latency effects.
Such packets include raw packetized data, such as raw IP packets, which lack destination information (i.e., destination port number). As such, the destination application may not be determined from the raw IP packets. In such situations, communication protocol stack 280 may transmit the received raw IP packets to all sockets registered to support the IP protocol, for example. This allows the payload data to be transmitted to the destination application. An Internet Control Messaging Protocol (ICMP) parsing engine, which responds to IP
packets, may also receive the raw packetized data. The well-known ICMP
parsing engine is defined in RFC 792, entitled "INTERNET CONTROL
MESSAGE PROTOCOL." It should be apparent from this description that communication protocol stack 280, for example, processes the received packets before it passes them up the stack to application 260, which reduces the amount of unencapsulation to be done by application 260.
Conversely, application 260 may transmit raw packetized data over the Um interface by using the sockets, which facilitates communications between communication protocol stack 280 and application 260. Further, application 260 may transmit raw packetized data over the Um interface. In turn, communication protocol stack 280 encapsulates the packetized or raw packetized data, for example, into IP packets and transmits them over the Um interface. In this example, communication protocol stack 280 provides a IP
header and a checksum in order to generate the IP packets. For ICMP, on the other hand, a specified protocol type may be copied into the IP header.
As stated above, application 260 may create a socket that allows data communications between at least one of the protocol layers 202, 204, 206, 208, 210, 212 and application 260 to reduce the latency inherent in the use of communication protocol stack 280. That is, application 260 may create a socket that bypasses the transport layer 202, the network layer 204, and the link layer 206, and thus allows application 260 to transmit payload data to, or receive payload data from, the RLP layer 210. Also, application 260 may create a socket that allows application 260 to transmit payload data to, or receive payload data from, the IS-95 layer 212.
In one embodiment, application 260 calls a function open_netlib () to open communication protocol stack 280 and to assign an application identification. The application identification allows multiple applications to communicate with communication protocol stack 280 (i.e., multi-tasking). As part of the call to function open netlib (), for example, application 260 specifies a pointer to a network callback function and to a socket callback function.
The network callback function is invoked to inform application 260 whenever network subsystem specified events, such as read from, write to, and dose the traffic channel (i.e., Urn) and/or a link-layer (i.e., PPP 206), have occurred (or have been enabled). The socket callback function is invoked to inform application 260 whenever socket specified events, such as read from, write to and dose the transport layer (i.e., TCP), have occurred (or have been enabled).
It should be apparent to one skilled in the art that a communication network comprises at least one of the traffic channel, the link-layer, and the transport layer.
Once communication protocol stack 280 has been opened, a function pppopen () is called to initiate a network subsystem connection, which includes the traffic channel and the link-layer. This is an application-wide call, which is not dependent on an individual socket. It, however, requires the application identification. Upon the establishment or failure of the network subsystem connection, the network callback function is invoked to provide a specified event notification. The network subsystem fails, for example, if the traffic channel is not established. Further, the network subsystem characteristics may be set with a call to function net_ioctl (). This call, for example, may specify the data rate of the sockets.
Once the network subsystem connection is established, a socket (or sockets) can be created and initialized through a call to function socket ( ).
Before the socket functions can be used, however, the call to function socket ( ) may return a socket descriptor. Then, application 260 may call a function async_select () to register specified events to receive asynchronous notification.
This registration may be implemented by application 260, as part of the function call, to specify the socket descriptor and a bit mask (i.e., multiple events OR'ed together) of the specified events requiring notification. If a specified event occurs (i.e., it is enabled), and it is detected by communication protocol stack 280 or API 270, for example, the socket callback function is invoked to provide asynchronous notification. The callback function may notify application 260 of the specified event by the use of a signal, a message, including a message over remote procedure call (RPC), or a hardware or software interrupt.
Once application 260 is notified of the specified event, then it may call function getnextevent ( ) to determine the specified events to service. This function returns a mask of the specified events that occurred for the specified socket descriptor. Also, it clears the bits in the mask of the specified events that occurred. Thus, application 260 may no longer receive notification of the disabled specified events. Application 260 must re-register (i.e., re-enable) these specified events through a subsequent call to function async select ().
In addition, application 260 may change the specified events registered for by clearing corresponding bits in the bit mask of specified events. If the bit is already cleared in the bit mask, then the request is simply ignored. In short, event notification may be disabled on a per-event basis, for example, through a call to function async_deselect ().
FIGS. 4 and 5 are flow charts for detecting the specified events. As shown in FIG. 4, for example, communication protocol stack 280 waits for application 5 260, in block 400, to register a specified event. After the specified event is registered, communication protocol stack 280, in block 402, polls a memory. In block 404, the specified event may be detected based on the polled information of block 402. In block 406, the write event is detected, for example, when the memory of the communication protocol stack 280 (i.e., the send queue) is 10 available to accept a sufficient amount of data. The data may be transmitted from application 260. If the polled information of block 404 is not satisfactory (i.e., the specified event has not occurred), then 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 a specified event, as indicated in block 500. During this time, an interrupt notice may be disabled. As such, the interrupt notice cannot trigger or be triggered. After the specified event is registered, as in block 500, the interrupt notice, in block 502, may be triggered based on the occurrence of the specified event. The read event, for example, occurs when data is written into = the memory of communication protocol stack 280 (i.e., the receive queue). Thus, in block 504, the read event is detected by communication protocol stack 280 when it receives the interrupt notice, which was triggered due to the occurrence of the event. The data stored in the memory of the communication protocol stack 280 may be from the communication network. Further, for the read event, the stored data may be transmitted to application 260.
Last, the dose event is detected when a socket is available for re-use because, for example, a data link connection, such as the transport layer, is terminated.
The following examples of an asynchronous connection (see FIG. 6) and an asynchronous input (see FIG. 7) are provided to illustrate the use of asynchronous event notification.
Referring to FIG. 6, both communication protocol stack 280 is entered and the callback functions are specified through the call to function open netlib ( ). The call to function pppopen () (A) initiates the network subsystem connection (B). After the network subsystem connection has been established, the callback function is invoked (C) to report the availability of the network subsystem.
Assuming that a socket has been opened and allocated, a call to function connect ( ) (D) initiates a TCP connection (E). Further, application 260 calls function async_select ( ) (F) to register the specified events to receive notification. In this example, the specified event of interest is the write event, which occurs upon establishing a connection.
Upon establishing the connection, the callback function is invoked if the specified event is registered in the mask. If it is, then the callback function is invoked (G) to provide asynchronous notification. Once application 260 is notified, it calls function getnextevent () (H) to determine which specified event occurred (I). Also, this call dears the bit of the event (i.e., the write event) in the mask (J). Application 260 must re-register subsequent notification of the specified event through the call to function async_select ().
In FIG. 7, an illustration of an asynchronous socket read is provided. To initiate the read, application 260 makes a call to function read () (A).
Assuming a lack of data to read, application 260 calls function async_select ( ) (B) to register an event (i.e., set the corresponding bit in the mask) to receive notification. In this example, the specified event of interest is the read event, which occurs when there is data to read by application 260.
Upon the storage of data in the receive queue, the callback function is invoked if the read event is specified in the mask. If it is, then the callback function is invoked (C) to provide asynchronous notification. Once application 260 is notified, it calls function getnextevent () (D) to determine which event occurred (E). Also, this call clears the bit of the event in the mask (F).
Application 260 must re-enable subsequent notification of the event through the call to function async_select ( ). Last, to read the data stored in the receive queue, application 260 makes the call to function read () (G).
In FIGS. 8-10, state machines of embodiments of the present invention are illustrated. In FIGS. 8-9, it is assumed that communication protocol stack is opened and the network subsystem connection (i.e., traffic channel, and link layer if necessary-the raw sockets may bypass the network subsystem) is established. One skilled in the art would appreciate that various names for the states are possible without departing from the scope of the present invention.
Conversely, application 260 may transmit raw packetized data over the Um interface by using the sockets, which facilitates communications between communication protocol stack 280 and application 260. Further, application 260 may transmit raw packetized data over the Um interface. In turn, communication protocol stack 280 encapsulates the packetized or raw packetized data, for example, into IP packets and transmits them over the Um interface. In this example, communication protocol stack 280 provides a IP
header and a checksum in order to generate the IP packets. For ICMP, on the other hand, a specified protocol type may be copied into the IP header.
As stated above, application 260 may create a socket that allows data communications between at least one of the protocol layers 202, 204, 206, 208, 210, 212 and application 260 to reduce the latency inherent in the use of communication protocol stack 280. That is, application 260 may create a socket that bypasses the transport layer 202, the network layer 204, and the link layer 206, and thus allows application 260 to transmit payload data to, or receive payload data from, the RLP layer 210. Also, application 260 may create a socket that allows application 260 to transmit payload data to, or receive payload data from, the IS-95 layer 212.
In one embodiment, application 260 calls a function open_netlib () to open communication protocol stack 280 and to assign an application identification. The application identification allows multiple applications to communicate with communication protocol stack 280 (i.e., multi-tasking). As part of the call to function open netlib (), for example, application 260 specifies a pointer to a network callback function and to a socket callback function.
The network callback function is invoked to inform application 260 whenever network subsystem specified events, such as read from, write to, and dose the traffic channel (i.e., Urn) and/or a link-layer (i.e., PPP 206), have occurred (or have been enabled). The socket callback function is invoked to inform application 260 whenever socket specified events, such as read from, write to and dose the transport layer (i.e., TCP), have occurred (or have been enabled).
It should be apparent to one skilled in the art that a communication network comprises at least one of the traffic channel, the link-layer, and the transport layer.
Once communication protocol stack 280 has been opened, a function pppopen () is called to initiate a network subsystem connection, which includes the traffic channel and the link-layer. This is an application-wide call, which is not dependent on an individual socket. It, however, requires the application identification. Upon the establishment or failure of the network subsystem connection, the network callback function is invoked to provide a specified event notification. The network subsystem fails, for example, if the traffic channel is not established. Further, the network subsystem characteristics may be set with a call to function net_ioctl (). This call, for example, may specify the data rate of the sockets.
Once the network subsystem connection is established, a socket (or sockets) can be created and initialized through a call to function socket ( ).
Before the socket functions can be used, however, the call to function socket ( ) may return a socket descriptor. Then, application 260 may call a function async_select () to register specified events to receive asynchronous notification.
This registration may be implemented by application 260, as part of the function call, to specify the socket descriptor and a bit mask (i.e., multiple events OR'ed together) of the specified events requiring notification. If a specified event occurs (i.e., it is enabled), and it is detected by communication protocol stack 280 or API 270, for example, the socket callback function is invoked to provide asynchronous notification. The callback function may notify application 260 of the specified event by the use of a signal, a message, including a message over remote procedure call (RPC), or a hardware or software interrupt.
Once application 260 is notified of the specified event, then it may call function getnextevent ( ) to determine the specified events to service. This function returns a mask of the specified events that occurred for the specified socket descriptor. Also, it clears the bits in the mask of the specified events that occurred. Thus, application 260 may no longer receive notification of the disabled specified events. Application 260 must re-register (i.e., re-enable) these specified events through a subsequent call to function async select ().
In addition, application 260 may change the specified events registered for by clearing corresponding bits in the bit mask of specified events. If the bit is already cleared in the bit mask, then the request is simply ignored. In short, event notification may be disabled on a per-event basis, for example, through a call to function async_deselect ().
FIGS. 4 and 5 are flow charts for detecting the specified events. As shown in FIG. 4, for example, communication protocol stack 280 waits for application 5 260, in block 400, to register a specified event. After the specified event is registered, communication protocol stack 280, in block 402, polls a memory. In block 404, the specified event may be detected based on the polled information of block 402. In block 406, the write event is detected, for example, when the memory of the communication protocol stack 280 (i.e., the send queue) is 10 available to accept a sufficient amount of data. The data may be transmitted from application 260. If the polled information of block 404 is not satisfactory (i.e., the specified event has not occurred), then 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 a specified event, as indicated in block 500. During this time, an interrupt notice may be disabled. As such, the interrupt notice cannot trigger or be triggered. After the specified event is registered, as in block 500, the interrupt notice, in block 502, may be triggered based on the occurrence of the specified event. The read event, for example, occurs when data is written into = the memory of communication protocol stack 280 (i.e., the receive queue). Thus, in block 504, the read event is detected by communication protocol stack 280 when it receives the interrupt notice, which was triggered due to the occurrence of the event. The data stored in the memory of the communication protocol stack 280 may be from the communication network. Further, for the read event, the stored data may be transmitted to application 260.
Last, the dose event is detected when a socket is available for re-use because, for example, a data link connection, such as the transport layer, is terminated.
The following examples of an asynchronous connection (see FIG. 6) and an asynchronous input (see FIG. 7) are provided to illustrate the use of asynchronous event notification.
Referring to FIG. 6, both communication protocol stack 280 is entered and the callback functions are specified through the call to function open netlib ( ). The call to function pppopen () (A) initiates the network subsystem connection (B). After the network subsystem connection has been established, the callback function is invoked (C) to report the availability of the network subsystem.
Assuming that a socket has been opened and allocated, a call to function connect ( ) (D) initiates a TCP connection (E). Further, application 260 calls function async_select ( ) (F) to register the specified events to receive notification. In this example, the specified event of interest is the write event, which occurs upon establishing a connection.
Upon establishing the connection, the callback function is invoked if the specified event is registered in the mask. If it is, then the callback function is invoked (G) to provide asynchronous notification. Once application 260 is notified, it calls function getnextevent () (H) to determine which specified event occurred (I). Also, this call dears the bit of the event (i.e., the write event) in the mask (J). Application 260 must re-register subsequent notification of the specified event through the call to function async_select ().
In FIG. 7, an illustration of an asynchronous socket read is provided. To initiate the read, application 260 makes a call to function read () (A).
Assuming a lack of data to read, application 260 calls function async_select ( ) (B) to register an event (i.e., set the corresponding bit in the mask) to receive notification. In this example, the specified event of interest is the read event, which occurs when there is data to read by application 260.
Upon the storage of data in the receive queue, the callback function is invoked if the read event is specified in the mask. If it is, then the callback function is invoked (C) to provide asynchronous notification. Once application 260 is notified, it calls function getnextevent () (D) to determine which event occurred (E). Also, this call clears the bit of the event in the mask (F).
Application 260 must re-enable subsequent notification of the event through the call to function async_select ( ). Last, to read the data stored in the receive queue, application 260 makes the call to function read () (G).
In FIGS. 8-10, state machines of embodiments of the present invention are illustrated. In FIGS. 8-9, it is assumed that communication protocol stack is opened and the network subsystem connection (i.e., traffic channel, and link layer if necessary-the raw sockets may bypass the network subsystem) is established. One skilled in the art would appreciate that various names for the states are possible without departing from the scope of the present invention.
The state machine, which may asynchronously transition between states, controls (i.e., enables and disables) the specified events, such as read, write, and dose. The specified events may be disabled at the start of operation and may be enabled in predetermined states to assist application 260 to identify the state of MS 110.
Also, API 270 reports specified status messages that are particular (i.e., not merely generic) to application 260 based on the state of API 270 and the type of function called by application 260. The specified status messages may reflect the state of the underlying communication network. The status messages are reported to application 260 as arguments of the function calls, for example.
In FIG. 8, for example, a state diagram for a TCP socket of API 270 is illustrated. The uninitialized socket begins in the "null" state 800. The socket does not "exist" because it has not been allocated, as of yet. The socket may be created and initialized through a call to function socket ( ), which returns the socket descriptor to use with socket-related functions. After the call to function socket (), the state machine transitions to an "initialize" state 805.
In the initialize 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 function close ( ). The call to function close ( ) releases all socket-related resources. On the other hand, a call to function connect ( ) initiates the TCP
connection and transitions the state machine into an "opening" state 810.
In the opening state 810, the state machine transitions to a "closed" state 815 whenever: (1) a network subsystem failure occurs, (2) a failure to establish the TCP connection, or (3) a changed IP address. Also, after a call to function close (), which terminates the TCP connection, the state machine transitions the socket into a "dosing" state 820 while the termination procedures are initiated.
Last, the state machine transitions to an "open" state 825 upon the TCP
connection being established.
In the open state 825, the socket is open to read and write. In particular, the write event is immediately enabled, while the read event is enabled based on whether data is stored into the memory of the communication protocol stack 280. The state machine transitions to the closed state 815 whenever: (1) the network subsystem failure occurs; (2) the failure to establish the TCI' connection; (3) an attempt to terminate the TCP connection, such as a TCP
reset, a TCP aborted, or a TCP closed initiated by a network server; and (4) the change of the IP address. An application initiated TCP connection termination, such as by a call to function close (), transitions the state machine to the closing state 820.
In the dosed state 815, the read, write and dose events are all asserted.
After a call to function dose (), which terminates the TCP connection, the state machine transitions the socket to the null state 800, which frees up the socket and makes it available for re-use.
In the dosing state 820, the state machine transitions to a "wait for close"
state 830 whenever: (1) the network subsystem failure occurs; (2) the attempt to terminate the TCP connection, such as the TCP reset, or the TCP dosed initiated by the network server; (3) an expiration of a timer and (4) the change of the IP
address. For protection against delay in terminating the TCP connection, the API 270 implements the timer, which is activated upon the initiating of the TCP
connection termination. As seen, the expiration of the timer transitions the state 15. machine to the wait for dose state 830.
In the wait for dose state 830, a call to function dose () terminates the TCP connection and transitions the state machine to the null state 800. The close event is asserted in this state 830. -Tables 1-3 illustrate specified status messages supported by API 270. In the null state (not shown in Tables 1-3), a specified status message, which is descriptive, that "no additional resources are available" may be reported to application 260.
Table 1 State Specified Status Messages for a Connect Function type Initialize If this were a blocking function call, the operation would block Opening Connection in progress Open Connection established Closing TCP connection does not exist due to lack of origination attempt, or the connection attempt failed Wait for TCP connection does not exist due to lack of origination Close attempt, or the connection attempt failed; or Generic network error; underlying network is not available Closed Generic network error; underlying network is not available;
Also, API 270 reports specified status messages that are particular (i.e., not merely generic) to application 260 based on the state of API 270 and the type of function called by application 260. The specified status messages may reflect the state of the underlying communication network. The status messages are reported to application 260 as arguments of the function calls, for example.
In FIG. 8, for example, a state diagram for a TCP socket of API 270 is illustrated. The uninitialized socket begins in the "null" state 800. The socket does not "exist" because it has not been allocated, as of yet. The socket may be created and initialized through a call to function socket ( ), which returns the socket descriptor to use with socket-related functions. After the call to function socket (), the state machine transitions to an "initialize" state 805.
In the initialize 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 function close ( ). The call to function close ( ) releases all socket-related resources. On the other hand, a call to function connect ( ) initiates the TCP
connection and transitions the state machine into an "opening" state 810.
In the opening state 810, the state machine transitions to a "closed" state 815 whenever: (1) a network subsystem failure occurs, (2) a failure to establish the TCP connection, or (3) a changed IP address. Also, after a call to function close (), which terminates the TCP connection, the state machine transitions the socket into a "dosing" state 820 while the termination procedures are initiated.
Last, the state machine transitions to an "open" state 825 upon the TCP
connection being established.
In the open state 825, the socket is open to read and write. In particular, the write event is immediately enabled, while the read event is enabled based on whether data is stored into the memory of the communication protocol stack 280. The state machine transitions to the closed state 815 whenever: (1) the network subsystem failure occurs; (2) the failure to establish the TCI' connection; (3) an attempt to terminate the TCP connection, such as a TCP
reset, a TCP aborted, or a TCP closed initiated by a network server; and (4) the change of the IP address. An application initiated TCP connection termination, such as by a call to function close (), transitions the state machine to the closing state 820.
In the dosed state 815, the read, write and dose events are all asserted.
After a call to function dose (), which terminates the TCP connection, the state machine transitions the socket to the null state 800, which frees up the socket and makes it available for re-use.
In the dosing state 820, the state machine transitions to a "wait for close"
state 830 whenever: (1) the network subsystem failure occurs; (2) the attempt to terminate the TCP connection, such as the TCP reset, or the TCP dosed initiated by the network server; (3) an expiration of a timer and (4) the change of the IP
address. For protection against delay in terminating the TCP connection, the API 270 implements the timer, which is activated upon the initiating of the TCP
connection termination. As seen, the expiration of the timer transitions the state 15. machine to the wait for dose state 830.
In the wait for dose state 830, a call to function dose () terminates the TCP connection and transitions the state machine to the null state 800. The close event is asserted in this state 830. -Tables 1-3 illustrate specified status messages supported by API 270. In the null state (not shown in Tables 1-3), a specified status message, which is descriptive, that "no additional resources are available" may be reported to application 260.
Table 1 State Specified Status Messages for a Connect Function type Initialize If this were a blocking function call, the operation would block Opening Connection in progress Open Connection established Closing TCP connection does not exist due to lack of origination attempt, or the connection attempt failed Wait for TCP connection does not exist due to lack of origination Close attempt, or the connection attempt failed; or Generic network error; underlying network is not available Closed Generic network error; underlying network is not available;
Connection attempt was refused due to a server reset;
Connection in progress timed out; or Network level IP address changed, which caused the TCP
connection to reset, due to a PPP resync Table 2 State Specified Status Messages for an I/O Function type Initialize TCP connection does not exist due to lack of origination attempt, or the connection attempt failed Opening If this were a blocking function call, the operation would block Open If this were a blocking function call, the operation would block (number of bytes read/written) Closing TCP connection does not exist due to lack of origination attempt, or the connection attempt failed Wait for TCP connection does not exist due to lack of origination Close attempt, or the connection attempt failed; or Generic network error; underlying network is not available Closed Generic network error; underlying network is not available;
Server reset the connection; receipt of a server reset;
TCP connection aborted due to a time-out or other reason; or TCP connection does not exist due to lack of origination attempt, or the connection attempt failed Table 3 State Specified Status Messages for a Close Function type Initialize Success-no error condition reported Opening If this were a blocking function call, the operation would block Open If this were a blocking function call, the operation would block Closing If this were a blocking function call, the operation would block Wait for Success-no error condition reported Close Closed Success-no error condition reported By way of example, FIG. 9 illustrates a state diagram for a UDP socket of API 270. The uninitialized socket begins in a "null" state 900. As noted above with respect to the null state 800, the socket does not "exist" because it has not been allocated. The socket may be created and initialized through a call to 5 function socket (), which returns the socket descriptor to use with socket-related functions. After the call to function socket (), the state machine transitions to an "open" state 905.
In the open state 905, the socket is open to read and write. In particular, the write event is immediately enabled, while the read event is enabled based 10 on whether data is stored into the memory of the communication protocol stack 280. The state machine transitions to a "dosed" state 910 whenever the network subsystem failure occurs. An application initiated UDP connection termination, such as by a call to function dose (), transitions the state machine to the null state 900.
Connection in progress timed out; or Network level IP address changed, which caused the TCP
connection to reset, due to a PPP resync Table 2 State Specified Status Messages for an I/O Function type Initialize TCP connection does not exist due to lack of origination attempt, or the connection attempt failed Opening If this were a blocking function call, the operation would block Open If this were a blocking function call, the operation would block (number of bytes read/written) Closing TCP connection does not exist due to lack of origination attempt, or the connection attempt failed Wait for TCP connection does not exist due to lack of origination Close attempt, or the connection attempt failed; or Generic network error; underlying network is not available Closed Generic network error; underlying network is not available;
Server reset the connection; receipt of a server reset;
TCP connection aborted due to a time-out or other reason; or TCP connection does not exist due to lack of origination attempt, or the connection attempt failed Table 3 State Specified Status Messages for a Close Function type Initialize Success-no error condition reported Opening If this were a blocking function call, the operation would block Open If this were a blocking function call, the operation would block Closing If this were a blocking function call, the operation would block Wait for Success-no error condition reported Close Closed Success-no error condition reported By way of example, FIG. 9 illustrates a state diagram for a UDP socket of API 270. The uninitialized socket begins in a "null" state 900. As noted above with respect to the null state 800, the socket does not "exist" because it has not been allocated. The socket may be created and initialized through a call to 5 function socket (), which returns the socket descriptor to use with socket-related functions. After the call to function socket (), the state machine transitions to an "open" state 905.
In the open state 905, the socket is open to read and write. In particular, the write event is immediately enabled, while the read event is enabled based 10 on whether data is stored into the memory of the communication protocol stack 280. The state machine transitions to a "dosed" state 910 whenever the network subsystem failure occurs. An application initiated UDP connection termination, such as by a call to function dose (), transitions the state machine to the null state 900.
15 In the dosed state 910, the read, write, and dose events are all enabled.
After a call to function dose (), which terminates the UDP connection, the state machine transitions the socket to the null state 900, which frees up the socket and makes it available for re-use.
Tables 4-6 illustrate specified status messages supported by API 270. In the null state (not shown in Tables 4-6), the specified status message that "no additional resources are available," as stated above, may be reported to application 260.
Table 4 State Specified Status Messages for a Connect Function type Open Success-no error condition reported Closed Generic network error; underlying network is not available Table 5 State Specified Status Messages for an I/O Function Type Open If this were a blocking function call, the operation would block (number of bytes read/written) Closed Generic network error; underlying network is not available Table 6 State Specified Status Messages for a Close Function Type Open Success-no error condition reported Closed Success-no error condition reported FIG. 10 illustrates a state diagram to control the network subsystem, such as the traffic channel (i.e., Um) and the link-layer (i.e., PPP 206). A call to function open netlib () opens the network subsystem, and initializes a socket into a "dosed" state 1000. A call to function pppopen () initiates the network subsystem connection, which transitions the socket to an "opening" state 1005.
Also, a page to the MS 110 by an incoming PPP call transitions the socket to the opening state 1005. In both cases, upon successful negotiation, the MS 110 attempts to synchronize and establish both RLP and PPP across the traffic channel.
In the opening state 1005, the socket transitions to an "open" state 1010 upon the network subsystem connection being established. On the other hand, the socket transitions back to the dosed state 1000 if the network subsystem connection is not established.
In the open state 1010, the callback function is invoked to identify to application 1060 specified events, such as read, write, and close, that are enabled. At this time, the MS 110 can communicate through the traffic channel.
The socket, however, transitions to the dosed state 1000 whenever network subsystem failure occurs, which invokes the callback function. An application initiated network subsystem connection termination, such as by a call to function dose (), transitions the socket to a "closing" state 1015.
In the closing state 1015, the socket transitions to the dosed state 1000 whenever the network subsystem connection is terminated. In the closed state 1000, the callback function is invoked to identify to application 260 specified events that are enabled.
Table 7 illustrates specified status messages that correspond to particular function calls, and that are supported by API 270.
Table 7 Function Call (and Specified Status Messages description) socket () Address not supported;
After a call to function dose (), which terminates the UDP connection, the state machine transitions the socket to the null state 900, which frees up the socket and makes it available for re-use.
Tables 4-6 illustrate specified status messages supported by API 270. In the null state (not shown in Tables 4-6), the specified status message that "no additional resources are available," as stated above, may be reported to application 260.
Table 4 State Specified Status Messages for a Connect Function type Open Success-no error condition reported Closed Generic network error; underlying network is not available Table 5 State Specified Status Messages for an I/O Function Type Open If this were a blocking function call, the operation would block (number of bytes read/written) Closed Generic network error; underlying network is not available Table 6 State Specified Status Messages for a Close Function Type Open Success-no error condition reported Closed Success-no error condition reported FIG. 10 illustrates a state diagram to control the network subsystem, such as the traffic channel (i.e., Um) and the link-layer (i.e., PPP 206). A call to function open netlib () opens the network subsystem, and initializes a socket into a "dosed" state 1000. A call to function pppopen () initiates the network subsystem connection, which transitions the socket to an "opening" state 1005.
Also, a page to the MS 110 by an incoming PPP call transitions the socket to the opening state 1005. In both cases, upon successful negotiation, the MS 110 attempts to synchronize and establish both RLP and PPP across the traffic channel.
In the opening state 1005, the socket transitions to an "open" state 1010 upon the network subsystem connection being established. On the other hand, the socket transitions back to the dosed state 1000 if the network subsystem connection is not established.
In the open state 1010, the callback function is invoked to identify to application 1060 specified events, such as read, write, and close, that are enabled. At this time, the MS 110 can communicate through the traffic channel.
The socket, however, transitions to the dosed state 1000 whenever network subsystem failure occurs, which invokes the callback function. An application initiated network subsystem connection termination, such as by a call to function dose (), transitions the socket to a "closing" state 1015.
In the closing state 1015, the socket transitions to the dosed state 1000 whenever the network subsystem connection is terminated. In the closed state 1000, the callback function is invoked to identify to application 260 specified events that are enabled.
Table 7 illustrates specified status messages that correspond to particular function calls, and that are supported by API 270.
Table 7 Function Call (and Specified Status Messages description) socket () Address not supported;
creates a socket and Invalid Application Identifier;
returns a socket descriptor Protocol is wrong type for socket;
Invalid or unsupported socket parameter;
Protocol not supported; or No more socket resources available connect () If this were a blocking function call, the operation initiates TCP connection would block;
Invalid socket descriptor;
Connection attempt was refused due to receipt of a server reset;
Connection timed out;
Application buffer not part of valid address space; invalid size specified for address length or message length;
Network level EP address changed, which caused the TCP connection to reset, due to a PPP resync;
Connection in progress;
Socket descriptor already connected;
Generic network error; underlying network is unavailable;
Invalid server address specified;
Address already in use; or Destination Address Required pppopen () If this were a blocking function call, the operation establishes network would block;
connection Invalid application identifier specified; or Termination of network connection in progress net ioctl () Invalid application identifier specified;
s e t s network Invalid request or parameter;
characteristics Network connection established; or Network connection in progress open netlib () No more applications available-maximum opens communication number of open applications exceeded protocol stack close_netlib () Invalid application identifier specified;
closes communication There are existing, allocated sockets; or protocol stack Network connection is still established bind () Invalid socket descriptor specified;
for client sockets, attaches Invalid or unsupported operation specified;
a local address and port Address already in use;
value to the socket Invalid operation; or Invalid address parameter specified close () Invalid socket descriptor specified; or doses a socket to free it for If this were a blocking function call, the operation re-use would block pppclose () If this were a blocking function call, the operation doses network connection would block;
Invalid application identifier specified; or Termination of network connection in progress netstatus () Invalid application identifier specified;
reports status of network Underlying network is unavailable;
connection Network connection established and available;
Network connection in progress;
Termination of network connection in progress;
No CDMA (i.e., traffic channel) service available;
CDMA service available, but origination failed because base station does not support service option; or CDMA service available, but origination failed;
however, not because base station does not support the service option async_select () Invalid socket descriptor specified registers specified events for a particular socket getnextevent () Invalid socket descriptor specified; or get the next socket Invalid application identifier specified descriptor and events that have occurred write () Invalid socket descriptor specified;
write a specified number No existing TCP connection;
of bytes-contiguous or Server reset the TCP connection;
non-contiguous buffers TCP connection aborted due to timeout or other failure;
Network level IP address changed, which caused the TCP connection to reset, due to a PPP resync;
TCP connection dosed;
Network unavailable;
Application buffer not valid part of address space; or No free buffers available for writing read () Invalid socket descriptor specified;
read a specified number of No existing TCP connection;
bytes-contiguous or non- Server reset the TCP connection;
contiguous buffers TCP connection aborted due to timeout or other failure;
Network level IP address changed, which caused the TCP connection to reset, due to a PPP resync;
TCP connection dosed;
Network unavailable;
Application buffer not valid part of address space;
No free buffers available for reading; or End of file marker received sendto () Invalid socket descriptor specified;
send a specified number of Address family not supported;
bytes No free buffers available for writing;
Network unavailable;
Application buffer not valid part of address space;
Specified option not supported; or Destination address requested recvfrom () Invalid socket descriptor specified;
reads a specified number Address family not supported;
of bytes No free buffers available for writing;
Network unavailable;
Application buffer not valid part of address space; or Specified option not supported In another embodiment, a machine may read a machine-readable medium comprising encoded information, such as encoded software code, to cause the processes described above that detects a specified event. The machine-5 readable medium may accept the encoded information from a storage device, such as a memory or a storage disk, or from the communication network. Also, the machine-readable medium may be programmed with the encoded information when the medium is manufactured. The machine may comprise at least one of application 260, communication protocol stack 280, and API 270, 10 while the machine-readable medium may comprise a memory or a storage disk.
Although this invention has been shown in relation to particular embodiments, it should not be considered so limited. Rather, the invention is limited only by the scope of the appended claims and their equivalents.
15 We claim:
returns a socket descriptor Protocol is wrong type for socket;
Invalid or unsupported socket parameter;
Protocol not supported; or No more socket resources available connect () If this were a blocking function call, the operation initiates TCP connection would block;
Invalid socket descriptor;
Connection attempt was refused due to receipt of a server reset;
Connection timed out;
Application buffer not part of valid address space; invalid size specified for address length or message length;
Network level EP address changed, which caused the TCP connection to reset, due to a PPP resync;
Connection in progress;
Socket descriptor already connected;
Generic network error; underlying network is unavailable;
Invalid server address specified;
Address already in use; or Destination Address Required pppopen () If this were a blocking function call, the operation establishes network would block;
connection Invalid application identifier specified; or Termination of network connection in progress net ioctl () Invalid application identifier specified;
s e t s network Invalid request or parameter;
characteristics Network connection established; or Network connection in progress open netlib () No more applications available-maximum opens communication number of open applications exceeded protocol stack close_netlib () Invalid application identifier specified;
closes communication There are existing, allocated sockets; or protocol stack Network connection is still established bind () Invalid socket descriptor specified;
for client sockets, attaches Invalid or unsupported operation specified;
a local address and port Address already in use;
value to the socket Invalid operation; or Invalid address parameter specified close () Invalid socket descriptor specified; or doses a socket to free it for If this were a blocking function call, the operation re-use would block pppclose () If this were a blocking function call, the operation doses network connection would block;
Invalid application identifier specified; or Termination of network connection in progress netstatus () Invalid application identifier specified;
reports status of network Underlying network is unavailable;
connection Network connection established and available;
Network connection in progress;
Termination of network connection in progress;
No CDMA (i.e., traffic channel) service available;
CDMA service available, but origination failed because base station does not support service option; or CDMA service available, but origination failed;
however, not because base station does not support the service option async_select () Invalid socket descriptor specified registers specified events for a particular socket getnextevent () Invalid socket descriptor specified; or get the next socket Invalid application identifier specified descriptor and events that have occurred write () Invalid socket descriptor specified;
write a specified number No existing TCP connection;
of bytes-contiguous or Server reset the TCP connection;
non-contiguous buffers TCP connection aborted due to timeout or other failure;
Network level IP address changed, which caused the TCP connection to reset, due to a PPP resync;
TCP connection dosed;
Network unavailable;
Application buffer not valid part of address space; or No free buffers available for writing read () Invalid socket descriptor specified;
read a specified number of No existing TCP connection;
bytes-contiguous or non- Server reset the TCP connection;
contiguous buffers TCP connection aborted due to timeout or other failure;
Network level IP address changed, which caused the TCP connection to reset, due to a PPP resync;
TCP connection dosed;
Network unavailable;
Application buffer not valid part of address space;
No free buffers available for reading; or End of file marker received sendto () Invalid socket descriptor specified;
send a specified number of Address family not supported;
bytes No free buffers available for writing;
Network unavailable;
Application buffer not valid part of address space;
Specified option not supported; or Destination address requested recvfrom () Invalid socket descriptor specified;
reads a specified number Address family not supported;
of bytes No free buffers available for writing;
Network unavailable;
Application buffer not valid part of address space; or Specified option not supported In another embodiment, a machine may read a machine-readable medium comprising encoded information, such as encoded software code, to cause the processes described above that detects a specified event. The machine-5 readable medium may accept the encoded information from a storage device, such as a memory or a storage disk, or from the communication network. Also, the machine-readable medium may be programmed with the encoded information when the medium is manufactured. The machine may comprise at least one of application 260, communication protocol stack 280, and API 270, 10 while the machine-readable medium may comprise a memory or a storage disk.
Although this invention has been shown in relation to particular embodiments, it should not be considered so limited. Rather, the invention is limited only by the scope of the appended claims and their equivalents.
15 We claim:
Claims (12)
1. A method for a mobile station communication protocol stack to detect a specified event, the method comprising:
communicating between the mobile station communication protocol stack and a communication network;
communicating between the mobile station communication protocol stack and a mobile station application through a mobile station application interface;
registering, by a mobile station application, the specified event;
triggering an interrupt notice whenever the specified event occurs;
and detecting, by the mobile station communication protocol stack, the specified event by the interrupt notice.
communicating between the mobile station communication protocol stack and a communication network;
communicating between the mobile station communication protocol stack and a mobile station application through a mobile station application interface;
registering, by a mobile station application, the specified event;
triggering an interrupt notice whenever the specified event occurs;
and detecting, by the mobile station communication protocol stack, the specified event by the interrupt notice.
2. The method of claim 1, wherein the specified event occurs whenever data is written into a memory.
3. The method of claim 1, wherein the specified event is at least one of a write, read and close events.
4. The method of claim 1, further comprising disabling, by the mobile station application, the specified event.
5. An apparatus for detecting a specified event, the apparatus comprising:
a mobile station communication protocol stack to communicate with a communication network; and a mobile station application interface to facilitate communications between the mobile station communication protocol stack and a mobile station application, wherein the mobile station application is adapted to register the specified event, wherein an interrupt notice is adapted to trigger whenever the specified event occurs, and wherein the mobile station communication protocol stack is adapted to detect the specified event by the interrupt notice.
a mobile station communication protocol stack to communicate with a communication network; and a mobile station application interface to facilitate communications between the mobile station communication protocol stack and a mobile station application, wherein the mobile station application is adapted to register the specified event, wherein an interrupt notice is adapted to trigger whenever the specified event occurs, and wherein the mobile station communication protocol stack is adapted to detect the specified event by the interrupt notice.
6. The apparatus of claim 5, wherein the specified event is at least one of a write, read and close events.
7. The apparatus of claim 5, wherein the specified event occurs whenever data is written into a memory.
8. The apparatus of claim 5, wherein the mobile station application is adapted to disable the specified event.
9. A machine-readable medium comprising encoded information, which when read by a machine causes the processes of:
communicating between a mobile station communication protocol stack and a communication network;
communicating between the mobile station communication protocol stack and a mobile station application through a mobile station application interface;
registering, by a mobile station application, a specified event;
triggering an interrupt notice whenever the specified event occurs;
and detecting, by the mobile station communication protocol stack, the specified event by the interrupt notice.
communicating between a mobile station communication protocol stack and a communication network;
communicating between the mobile station communication protocol stack and a mobile station application through a mobile station application interface;
registering, by a mobile station application, a specified event;
triggering an interrupt notice whenever the specified event occurs;
and detecting, by the mobile station communication protocol stack, the specified event by the interrupt notice.
10. The machine-readable medium of claim 9, wherein the specified event occurs whenever data is written into a memory.
11. The machine-readable medium of claim 9, wherein the specified event is at least one of a write, read and close events.
12. The machine-readable medium of claim 9, further comprising disabling, by the mobile station application, the specified event.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/539,498 US6542734B1 (en) | 2000-03-30 | 2000-03-30 | Method and apparatus for detecting specified events in a mobile station |
| US09/539,498 | 2000-03-30 | ||
| CA002404146A CA2404146A1 (en) | 2000-03-30 | 2001-03-29 | Method and apparatus for detecting specified events in a mobile station |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002404146A Division CA2404146A1 (en) | 2000-03-30 | 2001-03-29 | Method and apparatus for detecting specified events in a mobile station |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2706874A1 true CA2706874A1 (en) | 2001-10-11 |
Family
ID=24151474
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002404146A Abandoned CA2404146A1 (en) | 2000-03-30 | 2001-03-29 | Method and apparatus for detecting specified events in a mobile station |
| CA2706874A Abandoned CA2706874A1 (en) | 2000-03-30 | 2001-03-29 | Method and apparatus for detecting specified events in a mobile station |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002404146A Abandoned CA2404146A1 (en) | 2000-03-30 | 2001-03-29 | Method and apparatus for detecting specified events in a mobile station |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US6542734B1 (en) |
| EP (1) | EP1269717A2 (en) |
| JP (2) | JP2003529865A (en) |
| KR (1) | KR100804453B1 (en) |
| CN (1) | CN1199420C (en) |
| AU (1) | AU2001253009A1 (en) |
| CA (2) | CA2404146A1 (en) |
| HK (1) | HK1055190A1 (en) |
| WO (1) | WO2001076176A2 (en) |
Families Citing this family (88)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8352400B2 (en) | 1991-12-23 | 2013-01-08 | Hoffberg Steven M | Adaptive pattern recognition based controller apparatus and method and human-factored interface therefore |
| US10361802B1 (en) | 1999-02-01 | 2019-07-23 | Blanding Hovenweep, Llc | Adaptive pattern recognition based control system and method |
| US7853254B2 (en) * | 1993-08-31 | 2010-12-14 | Broadcom Corp. | Modular, portable data processing terminal for use in a radio frequency communication network |
| NZ506030A (en) * | 1998-12-28 | 2003-12-19 | Ntt Docomo Inc | Communication control system, communication method, server device, terminal, relay device, and communication system |
| US7966078B2 (en) | 1999-02-01 | 2011-06-21 | Steven Hoffberg | Network media appliance system and method |
| JP4745586B2 (en) * | 2000-03-30 | 2011-08-10 | クゥアルコム・インコーポレイテッド | Method and apparatus for mobile station applications to identify specified events |
| US6862276B1 (en) * | 2000-03-30 | 2005-03-01 | Qualcomm Incorporated | Method and apparatus for a mobile station application to receive and transmit raw packetized data |
| KR100612004B1 (en) * | 2000-04-06 | 2006-08-11 | 삼성전자주식회사 | Receipt data processing method in communication device supporting Bluetooth wireless communication |
| KR100352937B1 (en) * | 2000-05-20 | 2002-09-16 | 미래산업 주식회사 | Linear Electric Motor of Rotational and Linear Movement Type |
| KR20010109895A (en) * | 2000-06-03 | 2001-12-12 | 박종섭 | Method of discriminating network domain and method of interworking network using it on enhanced mobile telecommunication system |
| US6950657B1 (en) * | 2000-07-03 | 2005-09-27 | Lucent Technologies Inc. | Method for providing multiple points of connectivity to subscribers of wireless communication networks |
| KR100451786B1 (en) * | 2000-11-30 | 2004-10-08 | 엘지전자 주식회사 | Automatic management method for socket of mobile communication system |
| US6826387B1 (en) * | 2000-11-30 | 2004-11-30 | Palmsource, Inc. | Efficient service registration for legacy applications in a bluetooth environment |
| US6976054B1 (en) * | 2000-12-29 | 2005-12-13 | Nortel Networks Limited | Method and system for accessing low-level resources in a network device |
| US7269183B2 (en) * | 2001-04-27 | 2007-09-11 | Broadcom Corporation | System and method for connecting bluetooth-enabled devices to a personal computer |
| BR0209538A (en) * | 2001-05-08 | 2004-05-04 | Nortel Networks Ltd | Identification of unused resources in a packet data network |
| US7320033B2 (en) * | 2001-07-27 | 2008-01-15 | Intel Corporation | Dynamic local drive and printer sharing |
| US20030186699A1 (en) * | 2002-03-28 | 2003-10-02 | Arlene Havlark | Wireless telecommunications location based services scheme selection |
| US8918073B2 (en) * | 2002-03-28 | 2014-12-23 | Telecommunication Systems, Inc. | Wireless telecommunications location based services scheme selection |
| US8290505B2 (en) | 2006-08-29 | 2012-10-16 | Telecommunications Systems, Inc. | Consequential location derived information |
| US8027697B2 (en) * | 2007-09-28 | 2011-09-27 | Telecommunication Systems, Inc. | Public safety access point (PSAP) selection for E911 wireless callers in a GSM type system |
| US8126889B2 (en) | 2002-03-28 | 2012-02-28 | Telecommunication Systems, Inc. | Location fidelity adjustment based on mobile subscriber privacy profile |
| US7426380B2 (en) | 2002-03-28 | 2008-09-16 | Telecommunication Systems, Inc. | Location derived presence information |
| US9154906B2 (en) | 2002-03-28 | 2015-10-06 | Telecommunication Systems, Inc. | Area watcher for wireless network |
| US7478395B2 (en) * | 2002-09-23 | 2009-01-13 | Telefonaktiebolaget L M Ericsson (Publ) | Middleware application message/event model |
| US8666397B2 (en) | 2002-12-13 | 2014-03-04 | Telecommunication Systems, Inc. | Area event handling when current network does not cover target area |
| GB0316743D0 (en) * | 2003-07-17 | 2003-08-20 | Nokia Corp | Event based charging for mobile applications |
| CN100341276C (en) * | 2003-08-19 | 2007-10-03 | 华为技术有限公司 | Method for making business platform having external service ability |
| KR100575734B1 (en) | 2003-08-30 | 2006-05-03 | 엘지전자 주식회사 | Packet data receive method for mobile communication device |
| US7424293B2 (en) | 2003-12-02 | 2008-09-09 | Telecommunication Systems, Inc. | User plane location based service using message tunneling to support roaming |
| US7260186B2 (en) | 2004-03-23 | 2007-08-21 | Telecommunication Systems, Inc. | Solutions for voice over internet protocol (VoIP) 911 location services |
| US20080126535A1 (en) | 2006-11-28 | 2008-05-29 | Yinjun Zhu | User plane location services over session initiation protocol (SIP) |
| US20080090546A1 (en) | 2006-10-17 | 2008-04-17 | Richard Dickinson | Enhanced E911 network access for a call center using session initiation protocol (SIP) messaging |
| US7613923B2 (en) * | 2004-02-25 | 2009-11-03 | Watchguard Technologies, Inc. | Method and apparatus for controlling unsolicited messaging in real time messaging networks |
| US20050289554A1 (en) * | 2004-06-14 | 2005-12-29 | Nokia Corporation | System and method for application management |
| US7113128B1 (en) * | 2004-10-15 | 2006-09-26 | Telecommunication Systems, Inc. | Culled satellite ephemeris information for quick, accurate assisted locating satellite location determination for cell site antennas |
| US7629926B2 (en) | 2004-10-15 | 2009-12-08 | Telecommunication Systems, Inc. | Culled satellite ephemeris information for quick, accurate assisted locating satellite location determination for cell site antennas |
| US6985105B1 (en) | 2004-10-15 | 2006-01-10 | Telecommunication Systems, Inc. | Culled satellite ephemeris information based on limiting a span of an inverted cone for locating satellite in-range determinations |
| US7353034B2 (en) | 2005-04-04 | 2008-04-01 | X One, Inc. | Location sharing and tracking using mobile phones or other wireless devices |
| US9008613B2 (en) | 2005-07-06 | 2015-04-14 | Qualcomm Incorporated | Connection and data application billing |
| US8660573B2 (en) | 2005-07-19 | 2014-02-25 | Telecommunications Systems, Inc. | Location service requests throttling |
| US20070049288A1 (en) * | 2005-08-24 | 2007-03-01 | Lamprecht Leslie J | Creating optimum temporal location trigger for multiple requests |
| US9282451B2 (en) | 2005-09-26 | 2016-03-08 | Telecommunication Systems, Inc. | Automatic location identification (ALI) service requests steering, connection sharing and protocol translation |
| US7825780B2 (en) | 2005-10-05 | 2010-11-02 | Telecommunication Systems, Inc. | Cellular augmented vehicle alarm notification together with location services for position of an alarming vehicle |
| US7907551B2 (en) | 2005-10-06 | 2011-03-15 | Telecommunication Systems, Inc. | Voice over internet protocol (VoIP) location based 911 conferencing |
| US8467320B2 (en) | 2005-10-06 | 2013-06-18 | Telecommunication Systems, Inc. | Voice over internet protocol (VoIP) multi-user conferencing |
| US8150363B2 (en) | 2006-02-16 | 2012-04-03 | Telecommunication Systems, Inc. | Enhanced E911 network access for call centers |
| US8059789B2 (en) | 2006-02-24 | 2011-11-15 | Telecommunication Systems, Inc. | Automatic location identification (ALI) emergency services pseudo key (ESPK) |
| US7471236B1 (en) * | 2006-03-01 | 2008-12-30 | Telecommunication Systems, Inc. | Cellular augmented radar/laser detector |
| US9167553B2 (en) | 2006-03-01 | 2015-10-20 | Telecommunication Systems, Inc. | GeoNexus proximity detector network |
| US7899450B2 (en) * | 2006-03-01 | 2011-03-01 | Telecommunication Systems, Inc. | Cellular augmented radar/laser detection using local mobile network within cellular network |
| US8208605B2 (en) | 2006-05-04 | 2012-06-26 | Telecommunication Systems, Inc. | Extended efficient usage of emergency services keys |
| WO2008057477A2 (en) | 2006-11-03 | 2008-05-15 | Telecommunication Systems, Inc. | Roaming gateway enabling location based services (lbs) roaming for user plane in cdma networks without requiring use of a mobile positioning center (mpc) |
| US20080167018A1 (en) * | 2007-01-10 | 2008-07-10 | Arlene Havlark | Wireless telecommunications location based services scheme selection |
| US8769551B2 (en) * | 2007-02-06 | 2014-07-01 | Access Co., Ltd. | System and method for interprocess communication in electronic devices |
| US8050386B2 (en) | 2007-02-12 | 2011-11-01 | Telecommunication Systems, Inc. | Mobile automatic location identification (ALI) for first responders |
| US8185087B2 (en) | 2007-09-17 | 2012-05-22 | Telecommunication Systems, Inc. | Emergency 911 data messaging |
| US7929530B2 (en) | 2007-11-30 | 2011-04-19 | Telecommunication Systems, Inc. | Ancillary data support in session initiation protocol (SIP) messaging |
| US9130963B2 (en) | 2011-04-06 | 2015-09-08 | Telecommunication Systems, Inc. | Ancillary data support in session initiation protocol (SIP) messaging |
| US8068587B2 (en) | 2008-08-22 | 2011-11-29 | Telecommunication Systems, Inc. | Nationwide table routing of voice over internet protocol (VOIP) emergency calls |
| US8892128B2 (en) | 2008-10-14 | 2014-11-18 | Telecommunication Systems, Inc. | Location based geo-reminders |
| EP2347395A4 (en) | 2008-10-14 | 2016-11-02 | Telecomm Systems Inc | Location based proximity alert |
| US9301191B2 (en) | 2013-09-20 | 2016-03-29 | Telecommunication Systems, Inc. | Quality of service to over the top applications used with VPN |
| US8867485B2 (en) | 2009-05-05 | 2014-10-21 | Telecommunication Systems, Inc. | Multiple location retrieval function (LRF) network having location continuity |
| US8336664B2 (en) | 2010-07-09 | 2012-12-25 | Telecommunication Systems, Inc. | Telematics basic mobile device safety interlock |
| WO2012005769A1 (en) | 2010-07-09 | 2012-01-12 | Telecommunication Systems, Inc. | Location privacy selector |
| US8942743B2 (en) | 2010-12-17 | 2015-01-27 | Telecommunication Systems, Inc. | iALERT enhanced alert manager |
| US8688087B2 (en) | 2010-12-17 | 2014-04-01 | Telecommunication Systems, Inc. | N-dimensional affinity confluencer |
| WO2012141762A1 (en) | 2011-02-25 | 2012-10-18 | Telecommunication Systems, Inc. | Mobile internet protocol (ip) location |
| US8649806B2 (en) | 2011-09-02 | 2014-02-11 | Telecommunication Systems, Inc. | Aggregate location dynometer (ALD) |
| US9479344B2 (en) | 2011-09-16 | 2016-10-25 | Telecommunication Systems, Inc. | Anonymous voice conversation |
| US8831556B2 (en) | 2011-09-30 | 2014-09-09 | Telecommunication Systems, Inc. | Unique global identifier header for minimizing prank emergency 911 calls |
| US9264537B2 (en) | 2011-12-05 | 2016-02-16 | Telecommunication Systems, Inc. | Special emergency call treatment based on the caller |
| US9313637B2 (en) | 2011-12-05 | 2016-04-12 | Telecommunication Systems, Inc. | Wireless emergency caller profile data delivery over a legacy interface |
| US8984591B2 (en) | 2011-12-16 | 2015-03-17 | Telecommunications Systems, Inc. | Authentication via motion of wireless device movement |
| US9384339B2 (en) | 2012-01-13 | 2016-07-05 | Telecommunication Systems, Inc. | Authenticating cloud computing enabling secure services |
| US8688174B2 (en) | 2012-03-13 | 2014-04-01 | Telecommunication Systems, Inc. | Integrated, detachable ear bud device for a wireless phone |
| US9307372B2 (en) | 2012-03-26 | 2016-04-05 | Telecommunication Systems, Inc. | No responders online |
| US9544260B2 (en) | 2012-03-26 | 2017-01-10 | Telecommunication Systems, Inc. | Rapid assignment dynamic ownership queue |
| US9338153B2 (en) | 2012-04-11 | 2016-05-10 | Telecommunication Systems, Inc. | Secure distribution of non-privileged authentication credentials |
| US9313638B2 (en) | 2012-08-15 | 2016-04-12 | Telecommunication Systems, Inc. | Device independent caller data access for emergency calls |
| US9208346B2 (en) | 2012-09-05 | 2015-12-08 | Telecommunication Systems, Inc. | Persona-notitia intellection codifier |
| US9456301B2 (en) | 2012-12-11 | 2016-09-27 | Telecommunication Systems, Inc. | Efficient prisoner tracking |
| US8983047B2 (en) | 2013-03-20 | 2015-03-17 | Telecommunication Systems, Inc. | Index of suspicion determination for communications request |
| US9408034B2 (en) | 2013-09-09 | 2016-08-02 | Telecommunication Systems, Inc. | Extended area event for network based proximity discovery |
| US9516104B2 (en) | 2013-09-11 | 2016-12-06 | Telecommunication Systems, Inc. | Intelligent load balancer enhanced routing |
| US9479897B2 (en) | 2013-10-03 | 2016-10-25 | Telecommunication Systems, Inc. | SUPL-WiFi access point controller location based services for WiFi enabled mobile devices |
| US20210357788A1 (en) * | 2020-05-13 | 2021-11-18 | The Nielsen Company (Us), Llc | Methods and apparatus to generate computer-trained machine learning models to correct computer-generated errors in audience data |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2107047C (en) * | 1992-12-29 | 1998-04-28 | Alan M. Bentley | Switched circuit connection management over public data networks for wide area networks |
| JP3196618B2 (en) * | 1995-11-24 | 2001-08-06 | 株式会社日立製作所 | Personal computer and communication system using the same |
| WO1997021175A1 (en) * | 1995-12-08 | 1997-06-12 | Amsc Subsidiary Corporation | Mobile communications from computer aided dispatch system via a customer premises gateway for satellite communication system |
| US6044275A (en) | 1998-03-23 | 2000-03-28 | Ericsson Inc. | System and method for time defined delivery of short message service messages |
| KR20040007096A (en) * | 2002-07-16 | 2004-01-24 | 삼성전자주식회사 | Method for interfacing protocol porting in communication system |
| JP4167276B2 (en) * | 2006-06-23 | 2008-10-15 | 株式会社住化分析センター | Conductor fusing test method |
-
2000
- 2000-03-30 US US09/539,498 patent/US6542734B1/en not_active Expired - Lifetime
-
2001
- 2001-03-29 AU AU2001253009A patent/AU2001253009A1/en not_active Abandoned
- 2001-03-29 EP EP01926476A patent/EP1269717A2/en not_active Withdrawn
- 2001-03-29 CA CA002404146A patent/CA2404146A1/en not_active Abandoned
- 2001-03-29 JP JP2001573727A patent/JP2003529865A/en not_active Withdrawn
- 2001-03-29 KR KR1020027013071A patent/KR100804453B1/en active IP Right Grant
- 2001-03-29 CN CNB018073778A patent/CN1199420C/en not_active Expired - Lifetime
- 2001-03-29 CA CA2706874A patent/CA2706874A1/en not_active Abandoned
- 2001-03-29 WO PCT/US2001/010139 patent/WO2001076176A2/en not_active Application Discontinuation
-
2003
- 2003-10-15 HK HK03107432A patent/HK1055190A1/en not_active IP Right Cessation
-
2011
- 2011-04-07 JP JP2011085510A patent/JP5174206B2/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| WO2001076176A2 (en) | 2001-10-11 |
| HK1055190A1 (en) | 2003-12-24 |
| CN1199420C (en) | 2005-04-27 |
| KR100804453B1 (en) | 2008-02-20 |
| KR20030011288A (en) | 2003-02-07 |
| EP1269717A2 (en) | 2003-01-02 |
| AU2001253009A1 (en) | 2001-10-15 |
| WO2001076176A3 (en) | 2002-02-28 |
| CA2404146A1 (en) | 2001-10-11 |
| JP2003529865A (en) | 2003-10-07 |
| JP2011176858A (en) | 2011-09-08 |
| JP5174206B2 (en) | 2013-04-03 |
| US6542734B1 (en) | 2003-04-01 |
| CN1435039A (en) | 2003-08-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6542734B1 (en) | Method and apparatus for detecting specified events in a mobile station | |
| AU2001251105B2 (en) | Method and apparatus for a mobile station application to receive and transmit raw packetized data | |
| AU2001251105A1 (en) | Method and apparatus for a mobile station application to receive and transmit raw packetized data | |
| US20040162061A1 (en) | Method and apparatus for a mobile station application to identify specified events | |
| CA2402359A1 (en) | Method and apparatus for notifying a mobile station application of specified events | |
| CA2403813A1 (en) | Method and apparatus for a mobile station application to identify specified status messages | |
| CA2404347A1 (en) | Method and apparatus for servicing specified events by a mobile station application |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |