Terminal device, method for processing communication data inside the terminal device, and program for implementing the method

A terminal device, includes: a device driver section for controlling an interface section that is connected to a network; a protocol stack section that is connected to the network via the device driver section based on a communication protocol at higher than or equal to layer3 of OSI; and a middleware section that is interposed between the protocol stack section and the device driver section. If a send request for a frame to be sent is issued from the protocol stack section, the middleware section determines a priority of the send request based on header information at layer2 to layer4 of OSI within the send frame, and outputs the send request to the device driver section according to the priority determined. Also, if a receive request for a frame to be received is issued from the device driver section, the middleware section determines a priority of the receive request based on header information at layer2 to layer4 of OSI within the receive frame, and outputs the receive request to the protocol stack section according to the priority determined.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a terminal device, a method for processing communication data inside the terminal device, and a program for implementing the method. In particular, the present invention relates to a terminal device, a method for processing communication data inside the terminal device, and a program for implementing the method, which serve to send/receive a packet.

2. Description of the Related Art

An example of a conventional interface control section placed between a protocol stack and a device driver is disclosed in JP 2001-156793 A. The interface control section of JP 2001-156793 A analyzes a Media Access Control (hereinafter, referred to as “MAC”) address at layer2of Open Systems Interconnection (hereinafter, referred to as “OSI”) sent/received via the device driver, and sends the MAC address to the protocol stack or the device driver.

In the case of sending/receiving a packet for a high-priority communication protocol at higher than or equal to layer3of OSI (for example, video data sent as a Real-time Transport Protocol (hereinafter, referred to as “RTP”) packet), it is necessary to eliminate loss of time. Interface processing of JP 2001-156793 A is performed in a requested order irrespective of whether requests are sent from the device driver or the protocol stack. Therefore, as the load increases, the processing for sending/receiving the packet for a high-priority communication protocol is increasingly delayed in the protocol stack or the device driver.

SUMMARY OF THE INVENTION

The present invention therefore has an object to put a high priority on receiving processing in a protocol stack and/or sending processing in a device driver with respect to a specific packet assigned a high priority with as small delay as possible.

According to a specific example of the present invention, there is provided a terminal device including: a device driver section for controlling an interface section that is connected to a network; a protocol stack section that is connected to the network via the device driver section based on a communication protocol at higher than or equal to layer3of OSI; and a middleware section that is interposed between the protocol stack section and the device driver section, in which the middleware section includes a sending section that, if a send request for a frame to be sent (hereinafter, referred to as “send frame”) is issued from the protocol stack section, determines a send priority of the send request based on header information at layer2to layer4of OSI within the send frame, and then outputs the send request to the device driver section according to the send priority determined.

According to a specific example of the present invention, there is provided a method for processing communication data inside a terminal device that includes: a device driver section for controlling an interface section that is connected to a network; and a protocol stack section that is connected to the network via the device driver section based on a communication protocol at higher than or equal to layer3of OSI, the method including: (a) if a send request for a send frame is issued from the protocol stack section, determining a send priority of the send request based on header information at layer2to layer4of OSI within the send frame; and (b) outputting the send request to the device driver section according to the send priority determined.

According to a specific example of the present invention, there is provided a program capable of being executed by a computer that includes: a device driver section for controlling an interface section that is connected to a network; and a protocol stack section that is connected to the network via the device driver section based on a communication protocol at higher than or equal to layer3of OSI, the program including: (a) a process for, if a send request to a predetermined destination for a specific packet defined by a communication protocol at higher than or equal to layer5of OSI is issued from the protocol stack section in advance and if the send request is a first one of consecutive send requests, checking on header information of the specific packet, then registering into a cache table session information extracted from headers at layer2to layer4of OSI within a send frame carrying the specific packet, raising a send priority of the send request, and outputting the send request to the device driver section; and (b) a process for, if the send request is among the consecutive send requests other than the first one and if session information extracted from headers at layer2to layer4of OSI within a send frame carrying the specific packet is registered in the cache table, raising a send priority of the send request, and outputting the send request to the device driver section.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1is first used to describe an outline of a configuration of the present invention.

According to the present invention, middleware is interposed between a client driver and a higher-level application driver to thereby realize Quality of Service (hereinafter, referred to as “QoS”) of a wireless LAN. That is, a QoS middleware section1as the middleware is interposed between a device driver section2as a device driver for a LAN and a protocol stack section3at higher than or equal to layer3of OSI Reference Model such as Transmission Control Protocol/Internet Protocol (hereinafter, referred to as “TCP/IP”) for realizing LAN communication at higher than or equal to layer3of OSI.

The QoS middleware section1includes a sending section for passing receive data received from the protocol stack section3to the device driver section2for the LAN. The sending section includes a header comparison section111for directing send data toward multiple First In First Outs (hereinafter, referred to as “FIFOs”) included in a send FIFO section51, and a synthesis section112for synthesizing send requests for the send data outputted from the multiple FIFOs. Priorities are previously assigned to the multiple FIFOs. The header comparison section111compares information previously registered in a cache table53with session information extracted from each header information within a frame to be sent, to thereby determine the priority of the send data. The header comparison section111then queues the send request (send event) for the data to a FIFO conformed with the determined priority, so that predetermined high-priority data is sent to the wireless LAN. Note that the present invention is not limited to the wireless LAN, and may be applied to a low-speed communication line or other types of LAN communication.

In addition, the present invention may include a receiving section for passing receive data received from the device driver section2to the protocol stack section3at higher than or equal to layer3such as TCP/IP. Similarly to the sending section, the receiving section includes a header comparison section121, a receive FIFO section52having multiple FIFOs, and a synthesis section122, thereby offering QoS to the receive data.

Now, description is made of a first specific example of the present invention.FIG. 2is a block diagram showing a configuration of the first specific example of the present invention. InFIG. 2, a wireless terminal device is represented by a part surrounded by a dot-broken line. The wireless terminal device communicates with another device via a wireless LAN901using the Institute of Electrical and Electronic Engineers (hereinafter, referred to as “IEEE”) 802.11 standard.

The wireless terminal device includes: the QoS middleware section1; the protocol stack section3for controlling communication with the other device based on a communication protocol at higher than or equal to layer3of OSI; the device driver section2for passing data to/from the other device by using a communication protocol at the data link layer of the wireless LAN901; a wireless LAN interface section4for passing data to/from the other device by a communication protocol at the physical layer of the wireless LAN under the control of the device driver section2; the send FIFO section51having multiple FIFOs; the receive FIFO section52having multiple FIFOs; the cache table53; a watch dog timer section54; and a shared buffer section55. The QoS middleware section1and the device driver section2operate under program control by a processor (not shown) mounted inside the wireless terminal device. Note that a wireless LAN driver section911including the QoS middleware section1and the device driver section2is treated as a wireless LAN driver for controlling the wireless LAN interface section4. Also, the wireless terminal device is equipped with other function blocks and hardware that are not shown, but description thereof is omitted for convenience in explanation.

The shared buffer section55is allocated within a not-shown memory. Every time a frame is received from the wireless LAN901, one buffer is allocated to the frame in the shared buffer section55.

Each of the FIFOs of the send FIFO section51has an area allocated within a not-shown memory (for example, a RAM). A send request (send event) for a frame issued from the protocol stack section3to the device driver section2is queued to the send FIFO section51in a FIFO manner, and taken out therefrom. Further, the send FIFO section51has a send FIFO for each priority (storage area that is provided for each priority and used for queueing the send event). In this specific example, the send FIFO section51includes a high-order send FIFO511to which a high-priority send event is queued and a low-order send FIFO512to which a low-priority send event is queued.

Each of the FIFOs of the receive FIFO section52has an area allocated within a not-shown memory (for example, a RAM). A receive request (receive event) for a frame issued from the device driver section2to the protocol stack section3is queued in a FIFO manner, and taken out therefrom. Further, the receive FIFO section52has a receive FIFO for each priority (storage area that is provided for each priority and used for queueing the receive event). In this specific example, the receive FIFO section52includes a high-order receive FIFO521to which a high-priority receive event is queued and a low-order receive FIFO522to which a low-priority receive event is queued.

The cache table53includes an initial registration table531in which session information of an RTP frame (frame carrying an RTP packet) is previously registered and a temporary registration table532in which the session information is temporarily registered during session establishment. The cache table53is allocated within a not-shown memory (for example, a RAM). The initial registration table531is utilized for distinguishing a high-priority frame. The temporary registration table532is utilized for omitting a procedure for analyzing header information of a packet at higher than or equal to layer5of OSI. Further, in the case where the send request (send event) is issued from the protocol stack section3, the cache table53reads data in advance faster than a physical line speed, and rearranges the data, which is basically placed in a wait state according to the physical line speed, during standby (by utilizing conventional latency to send data). That is, the cache table53is utilized for providing prioritized communication according to the physical line speed. If the RTP packet includes the session information registered in the temporary registration table532or the initial registration table531, the receive request (receive event) issued from the device driver section2is queued to the high-order receive FIFO521, and if the RTP packet does not include the above-mentioned session information, the receive request is queued to the low-order receive FIFO522. Similarly, if the RTP packet includes the session information registered in the temporary registration table532or the initial registration table531, the send request (send event) issued from the protocol stack section3is queued to the high-order send FIFO511, and if the RTP packet does not include the above-mentioned session information, the receive request is queued to the low-order send FIFO512. If the send request or the receive request is queued to a high-order FIFO, the priority in a send queue or a receive queue becomes higher, respectively. Previously registered in the initial registration table531are multiple sets of session information each including: a MAC address of the other side corresponding to layer2of OSI; a protocol number and an IP address of the other side corresponding to layer3of OSI; a port number (in this case, port number of TCP or User Datagram Protocol (hereinafter, referred to as “UDP”)) of the other side corresponding to layer4of OSI; and a class of application packet at higher than or equal to layer5, which are to be compared with information within respective headers of a frame. In this case, the term “the other side” represents a source or a destination. Also, every time a new session is established, a set of session information is registered in the temporary registration table532, the set of session information including: MAC addresses of the source and the destination corresponding to layer2of OSI; a protocol number and IP addresses of the source and the destination corresponding to layer3of OSI; and port numbers (in this case, port number of TCP or UDP) of the source and the destination corresponding to layer4of OSI, which are included in respective headers of a frame. If the session is not established, the set of session information is deleted from the temporary registration table532.

The QoS middleware section1includes: a sending section11for performing priority control (priority processing) for a send request at the time of sending a frame to the wireless LAN901; a receiving section12for performing priority control (priority processing) for a send request at the time of receiving a frame from the wireless LAN901; an RTP session monitor section13for monitoring session information (connection information); and a pseudo protocol stack section14. Note that there exists a program (middleware driver) for causing the sending section11and the receiving section12of the QoS middleware section1to operate. This program is installed into the wireless terminal device together with a program for the device driver section2when the wireless LAN driver is installed into an access point.

The sending section11includes a header comparison section111and a synthesis section112. Upon relaying a send request for a frame, the header comparison section111compares session information extracted from each header information within a sent frame with the session information within the cache table53. According to a determined priority, the header comparison section111queues the send request (send event) to a corresponding FIFO within the send FIFO section51. The synthesis section112synthesizes output data (send event) from the send FIFO section51(performs identification of the send FIFOs within the send FIFO section51), and outputs the synthesized data to the pseudo protocol stack section14.

The receiving section12includes a header comparison section121and a synthesis section122. Upon relaying a receive request a frame from the pseudo protocol stack section14, the header comparison section121compares session information extracted from each header information within a received frame with the session information within the cache table53. According to a determined priority, the header comparison section121queues the receive request (receive event) to a corresponding FIFO within the receive FIFO section52. The synthesis section122synthesizes output data (receive event) from the receive FIFO section52(performs identification of the receive FIFOs within the receive FIFO section52), and outputs the synthesized data to the protocol stack section3.

FIG. 3is a schematic diagram showing how respective headers are allocated in a frame. The frame adopts the IEEE 802.3 standard and includes a frame header, an IP header, a TCP header (or a UDP header), a session header (RTP packet header), and a session data section.

The watchdog timer section54having multiple timers is utilized for monitoring the session information registered in the temporary registration table532of the cache table53. Each timer within the watchdog timer section54is activated (cleared and started) by the RTP session monitor section13, and issues a timer interruption when reaching a predetermined time. Note that in the case of activating the timer, a timer identification number is registered in the cache table53so as to correspond to the session information registered in the temporary registration table532.

The RTP session monitor section13activates the timer of the watchdog timer section54to thereby monitor the session information registered in the temporary registration table532of the cache table53. When the timer of the watchdog timer section54reaches the predetermined time (upon a time-out), the session information as a monitor object (session information corresponding to the timer identification number) registered in the temporary registration table532is deleted.

A program interface between the protocol stack section3and the QoS middleware section1is a Network Driver Interface Specification (which is a device driver interface jointly developed by 3Com Corporation and Microsoft Corporation, and hereinafter, referred to as “NDIS”) interface or a socket interface. Also, an interface between the QoS middleware section1and the device driver section2is an NDIS interface or a socket interface.

In the case of issuing a receive request from the device driver section2to the QoS middleware section1, the receive request is issued from the device driver section2through the NDIS interface (or the socket interface) as the program interface with respect to the protocol stack section3. The pseudo protocol stack section14receives the receive request through the program interface, and directly issues the receive request to the receiving section12of QoS middleware section1.

In the case of issuing a receive request from the receiving section11of the QoS middleware section1to the device driver section2, the pseudo protocol stack section14receives the send request from the receiving section11, and issues a send request to the device driver section2through the NDIS interface (or the socket interface) as the program interface with respect to the protocol stack section3.

Next, referring toFIGS. 2 to 9, description is made of operations of the first specific example according to the present invention.

Described here is an example in which it is checked whether communication data is an RTP frame for communicating on audio using Voice over Internet Protocol (hereinafter, referred to as “VoIP”) and video information of television conference, and if the communication data is the RTP frame, its processing priority in a send queue or a receive queue is raised. By raising the processing priority, RTP frames can be sent continuously to the wireless LAN901. Generally, in order to identify an RTP frame, reception of receive data from a protocol stack at higher than or equal to layer3of OSI such as TCP/IP starts comparison of the receive data with predetermined information for recognizing the RTP frame in a cache table. Information at layer2to layer5of OSI is used for the comparison. On the other hand, this specific example is characterized in that the comparison is made with the predetermined information at up to layer4of OSI, and the procedure for analyzing a frame at higher than or equal to layer5of OSI is omitted, thereby enhancing the processing speed. In this case, the session information of the frames carrying an RTP packet to be sent and an RTP packet to be received is previously set in the initial registration table531of the cache table53. Note that the information set in the initial registration table531is not limited to the session information of an RTP packet, and may include a packet for RTP control information or may be information on non-RTP data communication.

First, when information (send request for an RTP packet) is received from the protocol stack section3at a higher level, the QoS middleware section1starts priority checking on a frame.

Upon receiving a send request from the protocol stack section3, the QoS middleware section1passes control to the sending section11. The header comparison section111of the sending section11checks whether session information obtained by extracting port numbers of the source and the destination, IP addresses of the source and the destination, a protocol number, and MAC addresses of the source and the destination from respective header information within the frame is registered in the temporary registration table532of the cache table53(steps S101and S102ofFIG. 4)

If the session information is not registered in the temporary registration table532(note that the session information of the RTP frame that is sent or received at the start is not registered therein) in step S102, the header comparison section111of the sending section11checks whether session information obtained by extracting a port number of the source or the destination, an IP addresses of the source or the destination, a protocol number, and a MAC addresses of the source or the destination from the respective header information within the frame is registered in the initial registration table531of the cache table53(steps S103and S104ofFIG. 4).

If the session information is registered in the initial registration table531in step S104, the process advances to step S105. The header comparison section111of the sending section11checks whether a header information of a frame to be sent corresponding to a header area of the RTP packet at layer5of OSI is included in predetermined information (a pattern representing an RTP packet is previously registered in a class field for an application packet in cache table53) to thereby check whether the frame to be sent carries the RTP packet (steps S105and S106).

In the case of recognizing the RTP packet from its header information in step S106, the header comparison section111of the sending section11registers the port numbers of the source and the destination, the IP addresses of the source and the destination, the protocol number, and the MAC addresses of the source and the destination, which are extracted from respective header information within the frame to be sent, as a set of session information in the temporary registration table532(step S107). At the same time, the header comparison section111causes the RTP session monitor section13to activate (reset and start) the timer of the watchdog timer section54(step S108).

The RTP session monitor section13in this case registers the timer identification number for the timer of the watchdog timer section54to be activated into an area corresponding to the session information registered within the temporary registration table532in step S107, and activates the timer of the watchdog timer section54(steps S301and S302of FIG.8(1)).

After activating the timer of watchdog timer section54, the header comparison section111of the sending section11directs the send request toward the high-order send FIFO511as a send event, and queues the send request to the high-order send FIFO511(step S109ofFIG. 4). Note that the send event includes identification information of a send request, a storage area within a shared buffer section55, and length information of a frame to be relayed.

Note that if the header information within the frame to be sent does not corresponds to the header area of the RTP packet in step S106, the header comparison section111of the sending section11directs the send request toward the low-order send FIFO512as the send event, and queues the send request to the low-order send FIFO512(step S111).

Note that if the session information is not registered in the initial registration table531in step S104, the header comparison section111of the sending section11directs the send request toward the low-order send FIFO512as the send event, and queues the send request to the low-order send FIFO512(step S111).

On the other hand, unless sending processing is underway in the device driver section2(if the device driver section2is available), the synthesis section112of the sending section11checks whether the send request is queued to the send FIFO section51, and if the send request is queued, identification of the send FIFO is performed (steps S121to S124ofFIG. 5). The availability of the device driver section2is described above as “unless sending processing is underway”, but the synthesis section112of the sending section11may be operated depending on a remaining amount of data to be sent. That is, if the synthesis section112of the sending section11is operated depending on the remaining amount of data to be sent, send requests in a send queue can be rearranged according to their priorities by utilizing the latency to send during standby.

If the send request is queued to the high-order send FIFO511in step S124, the synthesis section112of the sending section11unconditionally issues a send request to the pseudo protocol stack section14based on the send event read out from the high-order send FIFO511(step S125). If the send request is not queued to the high-order send FIFO511in step S124, a send request is issued to the pseudo protocol stack section14based on the send event read out from the low-order send FIFO512(step S126).

The pseudo protocol stack section14that has received the send request issues a send request to the device driver section2through the NDIS interface (or the socket interface) based on the send event.

The device driver section2that has received the send request from the synthesis section112of the sending section11causes the wireless LAN interface section4to send the frame from the corresponding buffer of the shared buffer section55to the wireless LAN901based on the send request.

After the first RTP packet is sent as described above, in order to send consecutive RTP packets to the same device, the protocol stack section3issues a send request for a subsequent RTP packet to the QoS middleware section1.

If the session information is registered in the temporary registration table532, the header comparison section111causes the RTP session monitor section13to reactivate (reset and restart) the timer of the watchdog timer section54(step S110). At the same time, the header comparison section111directs the send request toward the high-order send FIFO511, and queues the send request to the high-order send FIFO511(step S109).

The RTP session monitor section13in this case extracts the timer identification number for the timer of the watchdog timer section54to be activated from the temporary registration table532, and reactivates (reset and restart) the timer (timer having the extracted timer identification number) of the watchdog timer section54(step S311of FIG.8(2)).

On the other hand, unless sending processing is underway in the device driver section2(if the device driver section2is available), the synthesis section112of the sending section11checks whether the send request is queued to the send FIFO section51, and if the send request is queued, the identification of the send FIFO is performed (steps S121to S124ofFIG. 5).

In step S124, the send request is queued to the high-order send FIFO511, so that the synthesis section112of the sending section11unconditionally issues a send request to the pseudo protocol stack section14based on the send event read out from the high-order send FIFO511(step S125).

The device driver section2that has received the send request from the pseudo protocol stack section14causes the wireless LAN interface section4to send the frame from the corresponding buffer of the shared buffer section55to the wireless LAN901based on the send request.

If a predetermined time has passed without sending the consecutive RTP packets to the same device, the corresponding timer of the watchdog timer section54causes a time-out. Then, the RTP session monitor section13deletes the session information (session information corresponding to the timer identification number for the timer causing a time-out) registered in the temporary registration table532(step S321of FIG.8(3)).

As described above, in the case of sending the consecutive RTP packets to the same device, the session information is already registered in the temporary registration table532of the cache table53. Accordingly, it is only necessary to check whether there is corresponding registration in the temporary registration table532based on the session information extracted from respective header information at layer2to layer4of OSI. That is, it is unnecessary to perform checking on the header information of the RTP packet, which is complicated processing. Further, the send event is queued to the high-priority queue (high-order send FIFO511), and a send request is issued from the queue with a higher priority, thereby enabling the high-speed processing.

If the wireless LAN interface section4receives a frame carrying an RTP packet from the wireless LAN901, the device driver section2causes the wireless LAN interface section4to store the received frame into the shared buffer section55. After the frame is stored, the device driver section2issues a receive request for the frame to the QoS middleware section1through the NDIS interface (or the socket interface).

If the QoS middleware section1that has received the receive request from the device driver section2passes control to the pseudo protocol stack section14, the pseudo protocol stack section14issues a receive request to the receiving section12(step S411ofFIG. 9).

The header comparison section121of the receiving section12checks whether session information obtained by extracting port numbers of the source and the destination, IP addresses of the source and the destination, a protocol number, and MAC addresses of the source and the destination from respective header information within the frame is registered in the temporary registration table532of the cache table53(steps S201and S202ofFIG. 6).

If the session information is not registered in the temporary registration table532(note that the session information of the RTP frame that is sent or received at the start is not registered therein) in step S202, the header comparison section121of the receiving section12checks whether session information obtained by extracting a port number of the source or the destination, an IP addresses of the source or the destination, a protocol number, and a MAC addresses of the source or the destination from the respective header information within the frame is registered in the initial registration table531of the cache table53(steps S203and S204ofFIG. 6).

If the header information is registered in the initial registration table531in step S204, the process advances to step S205. The header comparison section121of the receiving section12checks whether a header information of a frame to be received corresponding to a header area of the RTP packet at layer5of OSI is included in predetermined information to thereby check whether the frame to be received carries the RTP packet (steps S205and S206).

In the case of recognizing the RTP packet from its header information in step S206, the header comparison section121of the receiving section12registers the port numbers of the source and the destination, the IP addresses of the source and the destination, the protocol number, and the MAC addresses of the source and the destination, which are extracted from respective header information within the frame to be received, as a set of session information in the temporary registration table532(step S207). At the same time, the header comparison section121causes the RTP session monitor section13to activate (reset and start) the timer of the watchdog timer section54(step S208).

The RTP session monitor section13in this case registers the timer identification number for the timer of the watchdog timer section54to be activated into an area corresponding to the session information registered within the temporary registration table532in step S207, and activates the timer of the watchdog timer section54(steps S301and S302of FIG.8(1)).

After activating the timer of watchdog timer section54, the header comparison section121of the receiving section12directs the send request toward the high-order receive FIFO521as a send event, and queues the send request to the high-order receive FIFO521(step S209ofFIG. 6). Note that the receive event includes identification information of a receive request, a storage area within a shared buffer section55, and length information of a frame to be received.

Note that if the header information within the frame to be received does not corresponds to the header area of the RTP packet in step S206, the header comparison section121of the receiving section12directs the send request toward the low-order receive FIFO522as the send event, and queues the send request to the low-order receive FIFO522(step S211).

Note that if the session information is not registered in the initial registration table531in step S204, the header comparison section121of the receiving section12directs the receive request toward the low-order receive FIFO522as the receive event, and queues the receive request to the low-order receive FIFO522(step S211).

On the other hand, unless receiving processing is underway in the protocol stack section3(if the protocol stack section3is available), the synthesis section122of the receiving section12checks whether the receive request is queued to the receive FIFO section52, and if the receive request is queued, identification of the receive FIFO is performed (steps S221to S224ofFIG. 7).

If the receive request is queued to the high-order receive FIFO521in step S224, the synthesis section122of the receiving section12unconditionally issues a receive request to the protocol stack section3based on the receive event read out from the high-order receive FIFO521(step S225). If the receive request is not queued to the high-order receive FIFO521in step S224, a receive request is issued to the protocol stack section3according to the NDIS interface (or socket interface) based on the receive event read out from the low-order receive FIFO522(step S226).

The protocol stack section3that has received the receive request performs control using a communication protocol at higher than or equal to layer3of OSI based on the receive request.

After the first RTP packet is received as described above, in order to receive the consecutive RTP packets from the same device, the device driver section2issues a receive request for a subsequent RTP packet to the QoS middleware section1.

If the session information is registered in the temporary registration table532in step S202, the header comparison section121causes the RTP session monitor section13to reactivate (reset and restart) the timer of the watchdog timer section54(step S210) At the same time, the header comparison section121directs the receive request toward the high-order receive FIFO521, and queues the receive request to the high-order receive FIFO521(step S209)

The RTP session monitor section13in this case extracts the timer identification number for the timer of the watchdog timer section54to be activated from the temporary registration table532, and reactivates (reset and restart) the timer (timer having the extracted timer identification number) of the watchdog timer section54(step S311of FIG.8(2)).

On the other hand, unless receiving processing is underway in the protocol stack section3(if the protocol stack section3is available), the synthesis section122of the receiving section12checks whether the receive request is queued to the receive FIFO section52, and if the receive request is queued, identification of the receive FIFO is performed (steps S221to S224ofFIG. 7).

As the receive request is queued to the high-order receive FIFO521in step S224, the synthesis section122of the receiving section12unconditionally issues a receive request to the protocol stack section3based on the receive event read out from the high-order receive FIFO521(step S225).

The protocol stack section3that has received the receive request from the synthesis section122of the receiving section12performs control using a communication protocol at higher than or equal to layer3of OSI based on the receive request.

If a predetermined time has passed without receiving the consecutive RTP packets from the same device, the corresponding timer of the watchdog timer section54causes a time-out. Then, the RTP session monitor section13deletes the session information (session information corresponding to the timer identification number for the timer causing a time-out) registered in the temporary registration table532(step S321of FIG.8(3)).

Note that in the above-mentioned specific example, description is made relating to only an RTP packet, but the same operations also apply to a specific packet, other than the RTP packet, having a communication protocol at higher than or equal to layer5of OSI. The case of such a specific packet is naturally included in the present invention.

Also, in the above description, the RTP session monitor section13assigns one timer of the watchdog timer section54to each session for use, but may use one timer to monitor the time for all sessions. In this case, for example, the timer is set to interrupt into the RTP session monitor section13at constant intervals (for example, 1 ms). Every time session information is registered into the temporary registration table532of the cache table53, the RTP session monitor section13ensures an area (count area) where the time is counted in step S108(or step S208in the case of receiving). If a timer interruption occurs, the registered count area is counted up by +1, and cleared in step S110(or step S210in the case of receiving). If the count area reaches a predetermined value upon a timer interruption, the RTP session monitor section13deletes the corresponding session information.

As described above, according to this specific example, in the case of receiving the consecutive RTP packets from the same device, the session information is already registered in the temporary registration table532of the cache table53. Accordingly, it is only necessary to check whether there is corresponding registration in the temporary registration table532based on the session information extracted from respective header information at layer2to layer4of OSI. That is, it is unnecessary to perform checking on the header information of the RTP packet, which is complicated processing. Further, the receive event is queued to the high-priority queue (high-order receive FIFO521), and a receive request is issued from the queue with a higher priority, thereby enabling the high-speed processing.

According to this specific example, the QoS middleware section1for performing priority processing using FIFOs is provided between the device driver section2and the protocol stack section3that operates based on a high-level communication protocol. Accordingly, it is possible to reduce phenomena in which high-priority communication data waits to be sent to the wireless LAN901and in which high-priority communication data waits to be sent to the protocol stack section3.

According to this specific example, if the session information of the first RTP packet is registered into the temporary registration table532of the cache table53, the registered session information is regarded as the one for an RTP stream (consecutive RTP frames) until the session information is not used any more. Accordingly, it is possible to put a high priority on receiving processing in a protocol stack and/or sending processing in a device driver with respect to a specific packet assigned a high priority with as small delay as possible.

According to this specific example, the QoS middleware section1for the high-speed processing, which is interposed between the protocol stack section3and the device driver section2, includes the pseudo protocol stack section14. Accordingly, without replacing an interface between the protocol stack section3and the device driver section2with a special interface, the high-speed processing is possible with a conventional interface.

According to this specific example, the respective FIFOs of the send FIFO section51and the receive FIFO section52may be allocated within a memory (for example, RAM) provided to a wireless terminal device as standard equipment, and the program for the QoS middleware section1may be installed into the wireless terminal device. By such arrangement, QoS can be provided while the current system environment is utilized as it is. At the same time, there can be obtained a cost-effectiveness, which makes it unnecessary to newly purchase QoS-capable hardware adapted in view of the wait states.

Next, description is made of a second specific example of the present invention.FIG. 10is a block diagram showing a configuration of the second specific example of the present invention.

InFIG. 10, a wireless terminal device is represented by a part surrounded by a dot-broken line. The wireless terminal device communicates with another device via a wireless LAN901using the IEEE 802.11 standard. The wireless terminal device includes: the QoS middleware section6; the protocol stack section3for controlling communication with the other device based on a communication protocol at higher than or equal to layer3of OSI; the device driver section7for passing data to/from the other device by using a communication protocol at the data link layer of the wireless LAN901; a wireless LAN interface section4for passing data to/from the other device by a communication protocol at the physical layer of the wireless LAN under the control of the device driver section7; the send FIFO section51having multiple FIFOs; the receive FIFO section52having multiple FIFOs; the cache table53; a watchdog timer section54; and a shared buffer section55. In this case, the QoS middleware section6and the device driver section7operate under program control by a processor (not shown) mounted inside the wireless terminal device. Note that a wireless LAN driver section912including the QoS middleware section6and the device driver section7is treated as a wireless LAN driver912for controlling the wireless LAN interface section4. Also, the wireless terminal device is equipped with other function blocks and hardware that are not shown, but description thereof is omitted for convenience in explanation.

The second specific example is different from the first specific example in that the pseudo protocol stack section (denoted by reference numeral14inFIG. 2) is eliminated. That is, without using the NDIS interface nor the socket interface, sending and reception are directly made between the device driver section7and the QoS middleware section6, thereby enabling the higher-speed processing. Note that as the interface between the protocol stack section3and the QoS middleware section6, a standard interface such as the NDIS interface or the socket interface is used in order to maintain compatibility with the conventional environment.

The QoS middleware section6includes: a sending section61for performing priority control (priority processing) for a send request at the time of sending a frame to the wireless LAN901; a receiving section62for performing priority control (priority processing) for a receive request at the time of receiving a frame from the wireless LAN901; and an RTP session monitor section13for monitoring session information (connection information).

The sending section61includes a header comparison section611and a synthesis section612. Upon relaying a send request for a frame, the header comparison section611compares session information extracted from each header information within a sent frame with the session information within the cache table53. According to a determined priority, the header comparison section611queues the send request (send event) to a corresponding FIFO within the send FIFO section51. The synthesis section612synthesizes output data (send event) from the send FIFO section51(performs identification of the send FIFOs within the send FIFO section51), and outputs the synthesized data to the device driver section7.

The receiving section62includes a header comparison section621and a synthesis section622. Upon relaying a receive request for a frame, the header comparison section621compares session information extracted from each header information within a received frame with the session information within the cache table53. According to a determined priority, the header comparison section621queues the receive request (receive event) to a corresponding FIFO within the receive FIFO section52. The synthesis section622synthesizes output data (receive event) from the receive FIFO section52(performs identification of the receive FIFOs within the receive FIFO section52), and outputs the synthesized data to the protocol stack section3.

Note that the other configuration is the same as that of the first specific example, and therefore its description is omitted. InFIG. 10, the blocks exhibiting the same functions as those of the first specific example are denoted by the same reference numerals as those for the blocks ofFIG. 2.

Next, referring toFIGS. 3,8, and10to14, description is made of operations of the second specific example according to the present invention.

Described here is an example in which it is checked whether communication data is an RTP frame for communicating on audio using VoIP and video information of television conference, and if the communication data is the RTP frame, its processing priority is raised. By raising the processing priority, RTP frames can be sent continuously to the wireless LAN901. Generally, in order to identify an RTP frame, reception of receive data from a protocol stack at higher than or equal to layer3of OSI such as TCP/IP starts comparison of the receive data with predetermined information for recognizing the RTP frame in a cache table. On the other hand, this specific example is characterized in that the comparison is made with the predetermined information at up to layer4of OSI, and the procedure for analyzing a frame at higher than or equal to layers of OSI is omitted, thereby enhancing the processing speed. In this case, the session information of the frames carrying an RTP packet to be sent and an RTP packet to be received is previously set in the initial registration table531of the cache table53. Note that the information set in the initial registration table531is not limited to the session information of an RTP packet, and may include a packet for RTP control information or may be information on non-RTP data communication.

First, when information (send request for an RTP packet) is received from the protocol stack section3at a higher level, the QoS middleware section6starts priority checking on a frame.

Upon receiving a send request from the protocol stack section3, the QoS middleware section6passes control to the sending section61. The header comparison section611of the sending section61checks whether session information obtained by extracting port numbers of the source and the destination, IP addresses of the source and the destination, a protocol number, and MAC addresses of the source and the destination from respective header information within the frame is registered in the temporary registration table532of the cache table53(steps S501and S502ofFIG. 11).

If the session information is not registered in the temporary registration table532(note that the session information of the RTP frame that is sent or received at the start is not registered therein) in step S502, the header comparison section611of the sending section61checks whether session information obtained by extracting a port number of the source or the destination, an IP addresses of the source or the destination, a protocol number, and a MAC addresses of the source or the destination from the respective header information within the frame is registered in the initial registration table531of the cache table53(steps S503and S504ofFIG. 11).

If the session information is registered in the initial registration table531in step S504, the process advances to step S505. The header comparison section611of the sending section61checks whether a header information of a frame to be sent corresponding to a header area of the RTP packet at layer5of OSI is included in predetermined information to thereby check whether the frame to be sent carries the RTP packet (steps S505and S506).

In the case of recognizing the RTP packet from its header information in step S506, the header comparison section611of the sending section61registers the port numbers of the source and the destination, the IP addresses of the source and the destination, the protocol number, and the MAC addresses of the source and the destination, which are extracted from respective header information within the frame to be sent, as a set of session information in the temporary registration table532(step S507). At the same time, the header comparison section611causes the RTP session monitor section13to activate (reset and start) the timer of the watchdog timer section54(step S508).

The RTP session monitor section13in this case registers the timer identification number for the timer of the watchdog timer section54to be activated into an area corresponding to the session information registered within the temporary registration table532in step S507, and activates the timer of the watchdog timer section54(steps S301and S302of FIG.8(1)).

After activating the timer of watchdog timer section54, the header comparison section611of the sending section61directs the send request toward the high-order send FIFO511as a send event, and queues the send request to the high-order send FIFO511(step S509ofFIG. 11). Note that the send event includes identification information of a send request, a storage area within a shared buffer section55, and length information of a frame to be relayed.

Note that if the header information within the frame to be sent does not corresponds to the header area of the RTP packet in step S506, the header comparison section611of the sending section61directs the send request toward the low-order send FIFO512as the send event, and queues the send request to the low-order send FIFO512(step S511).

Note that if the session information is not registered in the initial registration table531in step S504, the header comparison section611of the sending section61directs the send request toward the low-order send FIFO512as the send event, and queues the send request to the low-order send FIFO512(step S511).

On the other hand, unless sending processing is underway in the wireless LAN device driver section41(if the device driver section41is available), the synthesis section612of the sending section61checks whether the send request is queued to the send FIFO section51, and if the send request is queued, identification of the send FIFO is performed (steps S521to S524ofFIG. 12).

If the send request is queued to the high-order send FIFO511in step S524, the synthesis section612of the sending section61unconditionally issues a send request to the device driver section7based on the send event read out from the high-order send FIFO511(step S525). If the send request is not queued to the high-order send FIFO511in step S524, a send request is issued to the device driver section7based on the send event read out from the low-order send FIFO512(step S526).

The device driver section7that has received the send request from the QoS middleware section6causes the wireless LAN interface section4to send the frame from the corresponding buffer of the shared buffer section55to the wireless LAN901based on the send request.

After the first RTP packet is sent as described above, in order to send the consecutive RTP packets to the same device, the protocol stack section3issues a send request for a subsequent RTP packet to the QoS middleware section6.

If the session information is registered in the temporary registration table532in step S502, the header comparison section611causes the RTP session monitor section13to reactivate (reset and restart) the timer of the watchdog timer section54(step S510). At the same time, the header comparison section611directs the send request toward the high-order send FIFO511, and queues the send request to the high-order send FIFO511(step S509).

The RTP session monitor section13in this case extracts the timer identification number for the timer of the watchdog timer section54to be activated from the temporary registration table532, and reactivates (reset and restart) the timer (timer having the extracted timer identification number) of the watchdog timer section54(step S311of FIG.8(2)).

On the other hand, unless sending processing is underway in the wireless LAN device driver section41(if the wireless LAN device driver section41is available), the synthesis section612of the sending section61checks whether the send request is queued to the send FIFO section51, and if the send request is queued, the identification of the send FIFO is performed (steps S521to S524ofFIG. 12).

In step S524, the send request is queued to the high-order send FIFO511, so that the synthesis section612of the sending section61unconditionally issues a send request to the device driver section7based on the send event read out from the high-order send FIFO511(step S525).

The device driver section7that has received the send request from the QoS middleware section6causes the wireless LAN interface section4to send the frame from the corresponding buffer of the shared buffer section55to the wireless LAN901based on the send request.

If a predetermined time has passed without sending the consecutive RTP packets to the same device, the corresponding timer of the watchdog timer section54causes a time-out. Then, the RTP session monitor section13deletes the session information (session information corresponding to the timer identification number for the timer causing a time-out) registered in the temporary registration table532(step S321of FIG.8(3)).

Note that in the second specific example, description is made relating to only an RTP packet, but the same operations also apply to a specific packet, other than the RTP packet, having a communication protocol at higher than or equal to layer5of OSI. The case of such a specific packet is naturally included in the present invention.

As described above, in the case of sending the consecutive RTP packets to the same device, the session information is already registered in the temporary registration table532of the cache table53. Accordingly, it is only necessary to check whether there is corresponding registration in the temporary registration table532based on the session information extracted from respective header information at layer2to layer4of OSI. That is, it is unnecessary to perform checking on the header information of the RTP packet, which is complicated processing. Further, the send event is queued to the high-priority queue (high-order send FIFO511), and a send request is issued from the queue with a higher priority, thereby enabling the high-speed processing.

If the wireless LAN interface section4receives a frame carrying an RTP packet from the wireless LAN901, the device driver section7causes the wireless LAN interface section4to store the received frame into the shared buffer section55. After the frame is stored, the device driver section7issues a receive request for the frame to the QoS middleware section6through the NDIS interface (or the socket interface).

If the QoS middleware section6that has received the receive request from the device driver section7passes control to the receiving section62. The header comparison section621of the receiving section62checks whether session information obtained by extracting port numbers of the source and the destination, IP addresses of the source and the destination, a protocol number, and MAC addresses of the source and the destination from respective header information within the frame is registered in the temporary registration table532of the cache table53(steps S601and S602ofFIG. 13).

If the session information is not registered in the temporary registration table532(note that the session information of the RTP frame that is sent or received at the start is not registered therein) in step S602, the header comparison section621of the receiving section62checks whether session information obtained by extracting a port number of the source or the destination, an IP addresses of the source or the destination, a protocol number, and a MAC addresses of the source or the destination from the respective header information within the frame is registered in the initial registration table531of the cache table53(steps S603and S604ofFIG. 13).

If the header information is registered in the initial registration table531in step S604, the process advances to step S605. The header comparison section621of the receiving section62checks whether a header information of a frame to be received corresponding to a header area of the RTP packet at layer5of OSI is included in predetermined information to thereby check whether the frame to be received carries the RTP packet (steps S605and S606).

In the case of recognizing the RTP packet from its header information in step S606, the header comparison section621of the receiving section62registers the port numbers of the source and the destination, the IP addresses of the source and the destination, the protocol number, and the MAC addresses of the source and the destination, which are extracted from respective header information within the frame to be received, as a set of session information in the temporary registration table532(step S607). At the same time, the header comparison section621causes the RTP session monitor section13to activate (reset and start) the timer of the watchdog timer section54(step S608).

The RTP session monitor section13in this case registers the timer identification number for the timer of the watchdog timer section54to be activated into an area corresponding to the session information registered within the temporary registration table532in step S607, and activates the timer of the watchdog timer section54(steps S301and S302of FIG.8(1)).

After activating the timer of the watchdog timer section54, the header comparison section621of the receiving section62directs the send request toward the high-order receive FIFO521as a send event, and queues the send request to the high-order receive FIFO521(step S609ofFIG. 13). Note that the receive event includes identification information of a receive request, a storage area within a shared buffer section55, and length information of a frame to be relayed.

Note that if the header information within the frame to be received does not corresponds to the header area of the RTP packet in step S606, the header comparison section621of the receiving section62directs the send request toward the low-order receive FIFO522as the send event, and queues the send request to the low-order receive FIFO522(step S611).

Note that if the session information is not registered in the initial registration table531in step S604, the header comparison section621of the receiving section62directs the receive request toward the low-order receive FIFO522as the receive event, and queues the receive request to the low-order receive FIFO522(step S611).

On the other hand, unless receiving processing is underway in the protocol stack section3(if the protocol stack section3is available), the synthesis section122of the receiving section12checks whether the receive request is queued to the receive FIFO section52, and if the receive request is queued, identification of the receive FIFO is performed (steps S621to S624ofFIG. 14).

If the receive request is queued to the high-order receive FIFO521in step S624, the synthesis section622of the receiving section62unconditionally issues a receive request to the protocol stack section3based on the receive event read out from the high-order receive FIFO521(step S625). If the receive request is not queued to the high-order receive FIFO521in step S624, a receive request is issued to the protocol stack section3according to the NDIS interface (or socket interface) based on the receive event read out from the low-order receive FIFO522(step S626).

The protocol stack2that has received the receive request performs control using a communication protocol at higher than or equal to layer3of OSI based on the receive request.

After the first RTP packet is received as described above, in order to receive the consecutive RTP packets from the same device, the device driver section7issues a receive request for a subsequent RTP packet to the QoS middleware section6.

If the session information is registered in the temporary registration table532in step S602, the header comparison section621causes the RTP session monitor section13to reactivate (reset and restart) the timer of the watchdog timer section54(step S610). At the same time, the header comparison section611directs the receive request toward the high-order receive FIFO521, and queues the receive request to the high-order receive FIFO521(step S609).

The RTP session monitor section13in this case extracts the timer identification number for the timer of the watchdog timer section54to be activated from the temporary registration table532, and reactivates (reset and restart) the timer (timer having the extracted timer identification number) of the watchdog timer section54(step S311of FIG.8(2)).

On the other hand, unless receiving processing is underway in the protocol stack section3(if the protocol stack section3is available), the synthesis section622of the receiving section62checks whether the receive request is queued to the receive FIFO section52, and if the receive request is queued, identification of the receive FIFO is performed (steps S621to S624ofFIG. 14).

As the receive request is queued to the high-order receive FIFO521in step S624, the synthesis section622of the receiving section62unconditionally issues a receive request to the protocol stack section3based on the receive event read out from the high-order receive FIFO521(step S625).

The protocol stack section3that has received the receive request from the synthesis section622of the receiving section62performs control using a communication protocol at higher than or equal to layer3of OSI based on the receive request.

If a predetermined time has passed without receiving the consecutive RTP packets from the same device, the corresponding timer of the watchdog timer section54causes a time-out. Then, the RTP session monitor section13deletes the session information (session information corresponding to the timer identification number for the timer causing a time-out) registered in the temporary registration table532(step S321of FIG.8(3)).

As described above, in the case of receiving the consecutive RTP packets from the same device, the session information is already registered in the temporary registration table532of the cache table53. Accordingly, it is only necessary to check whether there is corresponding registration in the temporary registration table532based on the session information extracted from respective header information at layer2to layer4of OSI. That is, it is unnecessary to perform checking on the header information of the RTP packet, which is complicated processing. Further, the receive event is queued to the high-priority queue (high-order receive FIFO521), and a send request is issued from the queue with a higher priority, thereby enabling the high-speed processing.

Thus, the QoS middleware section6for performing priority processing using FIFOs is provided between the device driver section7and the protocol stack section3that operates based on a high-level communication protocol. Accordingly, it is possible to reduce phenomena in which high-priority communication data waits to be sent to the wireless LAN901and in which high-priority communication data waits to be received to the protocol stack section3.

Also, if the session information of the first RTP packet is registered into the temporary registration table532of the cache table53, the registered session information registered into the temporary registration table532is regarded as the one for an RTP stream (consecutive RTP frames) until the session information is not used any more. Accordingly, it is possible to put a high priority on receiving processing in a protocol stack and/or sending processing in a device driver with respect to a specific packet assigned a high priority with as small delay as possible.

Further, the respective FIFOs of the send FIFO section51and the receive FIFO section52may be allocated within a memory (for example, RAM) provided to a wireless terminal device as standard equipment, and the program for the QoS middleware section6and the device driver section7maybe installed into the wireless terminal device. By such arrangement, QoS can be provided while the current system environment is utilized as it is. At the same time, there can be obtained a cost-effectiveness, which makes it unnecessary to newly purchase QoS-capable hardware adapted in view of the wait states.

Next, description is made of a third specific example.FIG. 15is a block diagram showing a configuration of the third specific example of the present invention.

The third specific example includes a computer81, a recording medium82, the device89, and the wireless LAN901. Examples of the recording medium82include a CD-R and a CD-RW. Note that the computer81communicates with the device89via the wireless LAN901.

The recording medium82stores a QoS middleware program821.

The computer81includes: a control section811that operates under program control by a not-shown processor (CPU); a memory section812that functions as a memory to which data can be written in and from which data can be readout (for example, RAM); a wireless LAN card813having wireless interface section4; a storage section814that functions as a nonvolatile recording medium device (for example, magnetic disk); a medium device815that functions as a driver unit for the recording medium82(for example, CD-R device, CD-RW device, etc.); and a watchdog timer section54.

The control section811includes the protocol stack section3, the QoS middleware section1and the device driver section2. In other words, in the case where a communication program stored in the storage section814is loaded into the a memory section812, the protocol stack section3, the QoS middleware section1and the device driver section2serve as a function block for causing a processor (CPU) to execute the program.

FIG. 15shows that the storage section814is configured to have the QoS middleware program821installed therein from the recording medium82, and stores programs including the QoS middleware section821.

Note that the respective blocks within the control section811are denoted by the same reference numerals and have the same functions as in the case of the first specific example (FIG. 2), and therefore their detailed description is omitted.

Next, referring toFIG. 15, description is made of an operation of the third specific example.

Now, in order to enhance the function of a wireless LAN driver installed in the computer81, a user sets the recording medium82in the medium device815to install the QoS middleware program821. Then, the control section811of the computer81stores the QoS middleware program821into the storage section814. After the QoS middleware program821is stored, the computer81is rebooted, and then a program including a QoS middleware program821is loaded to the memory section812. Thus, the control section811establishes the protocol stack section3, the QoS middleware section1, and the device driver section2.

Note that the respective blocks within the control section861after its establishment have the same operations as those described in the first specific example, and therefore their description is omitted.

Also, in the description of the third specific example, the QoS middleware program821is installed into the computer81from the recording medium82, but the QoS middleware program821may be installed into the computer86from the device89via the wireless LAN901.

Also, in the third specific example, the case of enhancing the computer81is described, but the device driver functioning as the QoS middleware program821and the device driver section2may be installed into the computer81as the a wireless LAN driver, or may be preinstalled. The operation of the processor (CPU) for executing the QoS middleware program821that has been installed is naturally the same as that of the processor (CPU) for executing the QoS middleware program821that has been enhanced.

Next, description is made of a fourth specific example.FIG. 16is a block diagram showing a configuration of the fourth specific example of the present invention.

The fourth specific example includes a computer81, a recording medium83, the device89, and the wireless LAN901. Examples of the recording medium82include a CD-R and a CD-RW. Note that the computer81communicates with the device89via the wireless LAN901.

The recording medium83stores a wireless LAN driver831having a QoS middleware program8311and a device driver8312.

The computer81includes: a control section811that operates under program control by a not-shown processor (CPU); a memory section812that functions as a memory to which data can be written in and from which data can be read out (for example, RAM); a wireless LAN card813having wireless interface section4; a storage section814that functions as a nonvolatile recording medium device (for example, magnetic disk); a medium device815that functions as a driver unit for the recording medium83(for example, CD-R device, CD-RW device, etc.); and a watchdog timer section54.

The control section811includes the protocol stack section3, the QoS middleware section6and the device driver section7. In other words, in the case where a communication program stored in the storage section814is loaded into the a memory section812, the protocol stack section3, the QoS middleware section6and the device driver section7serve as a function block for causing a processor (CPU) to execute the program.

FIG. 16shows that the storage section814is configured to have the wireless LAN driver831installed therein from the recording medium83, and stores programs including the QoS middleware program8311and the device driver8312.

Note that the respective blocks within the control section811are denoted by the same reference numerals and have the same functions as in the case of the second specific example (FIG. 10), and therefore their detailed description is omitted.

Next, referring toFIG. 16, description is made of an operation of the fourth specific example.

Now, in order to enhance the function of a wireless LAN driver installed in the computer81, a user sets the recording medium82in the medium device815to install the wireless LAN driver831. Then, the control section811of the computer81stores the QoS middleware section8311and the device driver8312into the storage section814. After the QoS middleware section8311and the device driver8312are stored, the computer81is rebooted, and then a program including a QoS middleware program8311is loaded to the memory section12. Thus, the control section811establishes the protocol stack section3, the QoS middleware section6and the device driver section7.

Note that the respective blocks within the control section811after its establishment have the same operations as those described in the second specific example, and therefore their description is omitted.

Also, in the description of the fourth specific example, the wireless LAN driver831is installed into the computer81from the recording medium82, but the wireless LAN driver831may be installed into the computer86from the device89via the wireless LAN901.

Also, in the fourth specific example, the case of enhancing the computer81is described, but the wireless LAN driver831may be installed into the computer81as the first installation of a wireless LAN driver, or may be preinstalled. The operation of the processor (CPU) for executing the QoS middleware program8311that has been installed is naturally the same as that of the processor (CPU) for executing the QoS middleware program8311that has been enhanced.

Next, description is made of a fifth specific example.FIG. 17is a block diagram showing a configuration of the fifth specific example of the present invention.

The fifth specific example includes a computer86, a recording medium84, the device89, and the wireless LAN901. Examples of the recording medium84include a CD-R and a CD-RW. Note that the computer86communicates with the device89via the wireless LAN901.

The recording medium84stores a wireless LAN driver841including a QoS middleware section8411and a device driver8412.

The computer86includes: a control section861that operates under program control by a not-shown processor (CPU); a memory section862that functions as a memory to which data can be written in and from which data can be read out (for example, RAM); a wireless LAN card863; a storage section864that functions as a nonvolatile recording medium device (for example, magnetic disk); and a medium device865that functions as a driver unit for the recording medium84(for example, CD-R device, CD-RW device, etc.).

The control section861includes the protocol stack section3. In other words, in the case where a communication program stored in the storage section864is loaded into the a memory section862, the protocol stack section3serves as a function block for causing a processor (CPU) to execute the program.

FIG. 17shows that the storage section864is configured to have the wireless LAN driver841installed therein from the recording medium84, and stores programs including the QoS middleware section8411and the device driver8412.

The wireless LAN card863includes: a control section8631that operates under program control by a not-shown processor (CPU) mounted to the wireless LAN card863; a memory section8632that functions as a memory to which data can be written in and from which data can be read out (for example, RAM); the wireless LAN interface section4; and the watchdog timer section54.

The control section8631includes the QoS middleware section6and the device driver section7. In other words, in the case where communication programs (in this case, the QoS middleware section8411and the device driver8412) stored in the storage section864are loaded into the memory section8632, the QoS middleware section6and the device driver section7serve as function blocks for causing the processor (CPU) to execute the program.

Note that the respective blocks within the control section861and the control section8631are denoted by the same reference numerals and have the same functions as in the case of the second specific example (FIG. 10), and therefore their detailed description is omitted.

Next, referring toFIG. 17, description is made of an operation of the fifth specific example.

Now, in order to enhance the function of a wireless LAN driver installed in the computer86, a user sets the recording medium84in the medium device865to install the wireless LAN driver841. Then, the control section861of the computer86stores the QoS middleware section8411and the device driver8412into the storage section864. After the QoS middleware section8411and the device driver8412are stored, the computer86is rebooted, and then a program including a protocol stack is loaded into the memory section862. Further, the QoS middleware section8411and the device driver8412are loaded. Thus, the control section861establishes the protocol stack section3, and the control section8631establishes the QoS middleware section6and the device driver section7.

Note that the respective blocks within the control section861after its establishment have the same operations as those described in the second specific example, and therefore their description is omitted.

Also, in the description of the fifth specific example, the wireless LAN driver841is installed into the computer86from the recording medium84, but the wireless LAN driver841may be installed into the computer86from the device89via the wireless LAN901.

Also, in the fifth specific example, the case of enhancing the computer86is described, but the wireless LAN driver841may be installed into the computer86as the first installation of a wireless LAN driver, or may be preinstalled. The operation of the processor (CPU) for executing the QoS middleware section8411that has been installed is naturally the same as that of the processor (CPU) for executing the QoS middleware section8411that has been enhanced.

In the first to fifth specific examples, the wireless LAN drivers are described as examples, but the communication mechanism used is not limited to a wireless LAN. Even if the case of using another LAN communication, the same operation naturally applies to the present invention.

Further, the memory capacity for an imaginary FIFO may not be fixed, but may be allowed to vary dynamically depending on information of the cache table53or on utilization efficiency for the FIFO. Reading data in advance for the FIFO may be made to appear faster than the physical line speed by a predetermined formula. For example, a speed faster by 10% may be set to thereby avoid reading data in a speed far faster than the physical line speed.

As has been described above, according to the present invention, it is possible to put a high priority on receiving processing in a protocol stack and/or sending processing in a device driver with respect to a specific packet assigned a high priority with as small delay as possible.

While the present invention has been described in connection with certain preferred embodiments, it is to be understood that the subject matter encompassed by the present invention is not limited to those specific embodiments. On the contrary, it is intended to include all alternatives, modifications, and equivalents as can be included within the spirit and scope of the following claims.