DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENTS

[0070] Referring now to the accompanying drawings, FIG. 1 illustrates a general overview of a remote network controller and a mobile data controller in accordance with an aspect of the present invention. In FIG. 1, a wired communication network 10 is shown as a host network system having communications controllers 15 and locally-attached devices 12 . The wired communication network 10 may be, for example, a Token Ring network or an Ethernet Local Area Network (LAN). The locally-attached devices 12 may include a personal computer, a workstation, a printer or network server, and reside at a plurality of dispersed locations. According to the present invention, a remote network controller 20 may also be provided which logically resides on the wired communication network 10 and acts as a protocol-appropriate communications controller to send and receive data to and from the communications network 10 and one or more remote or mobile devices 52 . For purposes of illustration, only one of the remote devices 52 is shown in FIG. 1 .

[0071] Remote devices 52 communicate via a mobile data controller 54 and a wireless radio-frequency (RF) communications link 55 created by the user's radio infrastructure 56 to the remote network controller 20 . The mobile data controller 54 may convert asynchronous data from the remote device 52 into an appropriate protocol format of the radio infrastructure 56 . In accordance with an aspect of the present invention, the remote devices 52 , although not physically connected to the wired communication network 10 , are logically connected to the wired communication network 10 through the radio infrastructure 56 and the remote network controller 20 and are indistinguishable from locally-attached devices 12 . The remote devices 52 may be, for example, a laptop computer, personal digital assistant (PDA), a credit card reader, or a global positioning system (GPS) receiver. The radio infrastructure 56 may comprise a conventional point to point or trunking radio system.

[0072] The logical connection created by the remote network controller 20 between the remote device 52 and the wired communication network 10 is “transparent” to the user of the remote device 52 , and to the wired communication network 10 . In accordance with an aspect of the invention, the remote network controller 20 takes data transported by the radio infrastructure 56 , irrespective of the format protocol of the radio infrastructure, and converts the data into a format protocol recognized by the wired network 10 . Similarly, the remote network controller 20 of the present invention takes data from the wired network 10 and converts the data into a format protocol recognized by the radio infrastructure 56 . Accordingly, the user of the remote device 52 does not have to perform any additional steps to send and receive data to and from the wired communication network 10 , and the wired communication network 10 does not have to perform any additional steps to send and receive data to and from the remote device 52 . The user of the remote device 52 interacts with the wired communication network 10 in a similar manner as a user of the locally-attached devices 12 . Similarly, the wired communication network 10 interacts with the remote device 52 in a similar manner as the wired communication network interacts with the locally-attached devices 12 .

[0073] Referring now to FIG. 2 , there is illustrated a block diagram of the basic components of the remote network controller 20 of the present invention. Each component of the remote network controller 20 will be generally described for introductory purposes and will later be described in greater detail below with reference to the accompanying drawings. The various components of the host data controller 22 and the mobile data controller 54 will also be discussed hereinafter with reference to FIGS. 13 and 25 , respectively.

[0074] As shown in FIG. 2 , the remote network controller 20 may comprise a service interface 30 , a mobile interface 24 , an interprocess communication manager 28 , a control process module 26 , and a console interface 34 . The remote network controller may be implemented through a collection of software program modules and hardware components working cooperatively. The remote network controller 20 itself may run on a standard platform, such as a personal computer (PC) equipped with a commercially available processor or multi-processor, e.g., an Intel or Motorola based processor or multi-processor, and a commercially available operating system, such as an MS-DOS or UNIX based operating system. The remote network controller 20 may also contain an Ethernet controller or suitable network controller card depending on the wired communication network 10 . In addition, the remote network controller 20 may include random access memory and physical storage media including hard disk and tape storage devices.

[0075] The wired communications network 10 is connected to the remote network controller 20 by the service interface 30 . The service interface 30 handles all network connections. If several wired communications networks 10 are present, one or more service interfaces 30 may be provided to handle wired network connectivity. The service interface 30 connects to an interprocess communication manager 26 . The interprocess communication manager 28 manages all inter-process message routing within the remote network controller 20 . One or more mobile interfaces 24 may also be provided to handle connectivity with the radio infrastructure(s) 56 . Each mobile interface 24 is also connected to the interprocess communication manager 28 . The control process module 26 of the remote network controller 20 is provided to process management functions and data integrity. The control process module 26 is connected to the interprocess communication manager 28 and the console interface 34 . The console interface 34 allows for user configuration and reporting of data.

[0076] As further illustrated in FIG. 2 , the remote network controller 20 may be connected to a host data controller 22 . One or more host data controllers 22 may be provided for connecting the remote network controller 20 to specific radio infrastructures 56 , e.g., a Motorola trunked radio. The host data controller 22 may be connected to the mobile interface 24 of the remote network controller 20 .

[0077] In the field, the remote device 52 is connected to the mobile data controller 54 which, in turn, is connected to the radio infrastructure 56 for transmitting and receiving data. The mobile data controller 54 is responsible for connecting the remote device 52 to the radio infrastructure 56 and to provide protocol-independent asynchronous serial data transfer to and from the remote device 52 .

[0078] In order to provide transparent data transportation, whereby the network protocols and the protocols of the radio infrastructure 56 are transparent or invisible to the user, inbound asynchronous data from the remote device 52 is collected and transported to the wired communication network 10 in packets over the radio infrastructure 56 . The data is sent using the existing protocols of the radio infrastructure 56 . The remote network controller 20 accepts the data and encapsulates it into the appropriate protocol used by the wired communication network 10 . The data is passed to the wired communication network 10 in a similar fashion for passing data from any of the other locally-attached devices 12 . Similarly, outbound data to the remote device 52 from the wired communication network 10 is removed from the network protocol by the remote network controller 20 . The remote network controller then encapsulates the data into the appropriate protocol associated with the radio infrastructure 56 and sends the data over the radio infrastructure 56 to the mobile data controller 54 . Upon receipt of the data, the mobile data controller 54 removes the data from the radio infrastructure protocol and asynchronously sends the data to the remote device 52 .

[0079] In accordance with the present invention, multiple wired networks 10 with different protocols may be linked to multiple RF environments in any combination by incorporating the remote network controller and mobile data controller of the present invention.

[0080] FIG. 3 is a high-level flow chart for transporting outbound data from the wired communication network 10 to the remote device 52 . As shown in FIG. 3 , when data is to be sent to the remote device 52 , the service interface 30 of the remote network controller 20 accepts data from the wired communication network 10 at step 500 . The service interface 30 then converts the data from the protocol used by the wired communication network 10 and encapsulates it into an internal protocol used by the remote network controller 20 at step 502 . In addition, the service interface 30 may receive routing information from the wired communication network 10 as to what remote device 52 the data is to be passed, e.g., a network address or device identifier of the remote device 52 .

[0081] At step 504 , the service interface 30 forwards the data to the interprocess communication manager 28 . The interprocess communication manager 28 accepts the data at step 506 and, at step 508 , places the data in a queue for the appropriate destination mobile interface 24 . The destination mobile interface 24 may depend on the radio infrastructure 56 employed by the user. The outbound data that is to be passed from the interprocess communications manager 28 to the mobile interface 24 may be encapsulated in an internal protocol of the remote network controller 20 , along with routing information to specify the remote device 52 to which the data is to be sent. At step 510 , the interprocess communication manager 28 notifies the mobile interface 24 that the data to be sent to the remote device 52 is queued for the mobile interface. The particular mobile interface 24 that the data is queued for depends on the particular radio infrastructure 56 employed to communicate with the destination remote device 52 . At step 512 , the mobile interface 24 requests that the queued data be sent from the interprocess communication manager 28 . The mobile interface 24 may request data when it is free to send the data to a destination remote device 52 and not handling another process. At step 514 , the mobile interface 24 accepts the queued data from the interprocess communication manager 28 . Thereafter, at step 516 , the mobile interface 24 determines, based on the queued data, the destination node address of the remote device 52 to which the data is to be sent. At step 518 , the mobile interface 24 forwards the data to the appropriate host data controller 22 so that it may be sent over the radio infrastructure 56 at step 520 . According to an aspect of the present invention, the host data controller 22 may receive the data, remove it from the internal protocol and encapsulate the data into a packet determined by the protocol used by the radio infrastructure 56 . The packet of data may be broadcasted over the radio infrastructure 56 so as to enable the host data controller 22 to communicate with multiple mobile data controllers 54 simultaneously. The broadcasted data packet may include the identification of the specific mobile data controller 54 to which the packet is to be delivered, so that only uniquely identified mobile controller(s) may accept the packet.

[0082] Referring again to FIG. 3 , at step 522 , the mobile data controller 54 receives the data from the remote radio infrastructure 56 and decodes the data. The data packet, once received by the mobile data controller 54 , is accepted and the data is removed from the packet. At step 524 , the mobile data controller 54 validates the data and, at step 526 , sends an acknowledgment or rejection message to the host data controller 22 via the radio infrastructure 56 . According to the present invention, the remote network controller 20 and the host data controller 22 may be responsible for ensuring the integrity of the data transported over the radio infrastructure. As such, an error detection/retry mechanism may be employed to detect and correct data transmission errors. After the integrity of the data is verified, the mobile data controller 54 at step 528 will forward the data to the remote device 52 . The data may be asynchronously transferred to the remote device 52 through a serial connection.

[0083] FIG. 4 is a high-level flow chart illustrating the processing of inbound data from the remote device 52 to the wired communication network 10 . At step 550 , the mobile data controller 54 accepts data from the remote device 52 . At step 552 , the mobile data controller 54 formats and sends the data to the remote network controller 20 via the radio infrastructure 56 , which may comprise a modem. The data may be transmitted using the appropriate protocol of the radio infrastructure 56 . The data may be modulated within the mobile data controller 54 prior to transmission via the radio infrastructure 56 . The mobile data controller 52 may place the data from the remote device 52 into packets to be sent over the radio infrastructure 56 . The packet size can be determined by one of three methods. The first is a maximum packet size. Once an upper limit of data is accumulated, the mobile data controller 54 may send the packet of information to the host data controller 22 . For example, once 256 bytes of data are collected, the data may be sent by the radio infrastructure 56 over the RF communications link 55 . The second method is a maximum time to wait before sending data. In this case the mobile data controller 54 will send a packet after waiting a predetermined period of time, no matter how much data is accumulated. The third method involves the mobile data controller 54 detecting a predefined “end-of-packet” character which causes all accumulated data to be transmitted.

[0084] At step 554 , the host data controller 22 receives and decodes the data packet from the protocol of the radio infrastructure 56 . Generally, the data arrives as a packet of a predetermined size. At step 556 , the host data controller 22 validates the data and, thereafter, sends at step 558 an acknowledgment or rejection message to the mobile data controller 54 based on the validation process. According to an aspect of the present invention, the host data controller 22 may determine if the transmitted data packet is correct, or in error. The host data controller 22 may also determine if the data packet has arrived in the proper sequence, and that the packet is not a duplicate. As discussed above, the inbound data may be removed from the packet and encapsulated in the internal protocol used by the remote network controller 20 . The internal protocol may contain additional information, such as the identification of the mobile data controller 54 which sent the information.

[0085] At step 560 , the host data controller 22 forwards the data to the mobile interface 24 . The mobile interface 24 accepts the data from the host data controller 22 at step 562 . The mobile interface 24 validates the address of the source of the data (e.g., the particular mobile data controller 54 or remote device 52 ) at step 562 . At step 566 , the mobile interface 24 forwards the data to the interprocess communication manager 28 , which accepts the data at step 568 . The mobile interface may also pass the routing information specifying the remote device 52 from which the data originated. At step 570 , the interprocess communication manager 28 places the data into a queue for the destination service interface 30 . The particular destination service interface 30 will depend upon which wired communication network 10 the data is to be delivered. Included in the information which is passed to the service interface 30 is the destination address (i.e., the communication network 10 to which the data is to be delivered). At step 572 , the service interface 30 , when available to handle data, requests the data from the interprocess communication manager 28 . The service interface 30 accepts the data at step 576 and converts the data into an appropriate form, i.e., protocol, usable by the wired communication network 10 at step 578 . As a result, the data may be passed to the hardware device (e.g., an Ethernet controller) using the protocol required by the wired communication network 10 . This configuration allows any existing network interface card to be used in conjunction with the remote network controller 20 , because the data is placed into the appropriate network protocol by the service interface 30 before it is transmitted to the wired network. At step 580 , the service interface 30 forwards the data to the wired communication network 10 .

[0086] The validation process of the outbound data depicted in FIG. 3 and inbound data depicted in FIG. 4 does not depend on the type of wired communication network employed by the user. Through a single validation process performed by the host data controller 22 and the mobile data controller 54 (see steps 524 and 526 in FIG. 3 and steps 556 and 558 in FIG. 4 ), the integrity of the data transmitted from the wired communication network 10 to the remote device 52 through the radio infrastructure 56 is ensured. This validation process may include, for example, an error detection and retry mechanism to detect errors and to cause (when necessary) the retransmission of the data.

[0087] Referring now to FIG. 5 , there is illustrated a block diagram of the basic components of the mobile interface 24 of the remote network controller 20 of the present invention. As noted above, the mobile interface 24 is responsible for interfacing the remote network controller 20 with the host data controller 22 and the radio infrastructure 56 . The mobile interface 24 may be a software interface that records statistical information related to inbound and outbound data. The mobile interface 24 may also be responsible for error detection and correction, and establishing and managing the mobile data sessions with the remote devices 52 . The number of mobile interfaces 24 provided in the remote network controller 20 depends on the number of different types of radio infrastructures 56 employed by the user. Each type of radio infrastructure 56 may have its own associated mobile interface 24 .

[0088] As shown in FIG. 5 , the mobile interface 24 may include an event handler and multithreading dispatcher 60 , a process initialization module 62 , a mobile session manager 64 , an inbound data event handler 66 , an outbound data event handler 68 , a process termination module 70 and a host data controller interface module 72 . The event handler and multithreading dispatcher 60 may contain high-level logic and be used to control the overall execution flow of the mobile interface 24 . The process initialization module 62 may be utilized to acquire resources and establish the operation environment for the mobile interface 24 process. The process initialization module 62 may also be provided to initialize the host data controller 22 .

[0089] According to the present invention, the mobile session manager 64 may be provided to control the communications environment between the mobile data controller 54 and the host data controller 22 . The inbound data event handler 66 responds to signals from the host data controller 22 indicating that inbound data is available and preprocess session control information. The outbound data event handler 68 is provided to respond to signals from the interprocess communication manager 28 indicating that outbound data is available or that a session control function is required. The process termination module 70 functions to release previously-acquired resources and terminate the mobile interface 24 process efficiently. The host data controller interface module 72 handles low-level interaction with the associated host data controller(s) 22 .

[0090] The process flow of the event handler and multithreading dispatcher 60 will now be described with reference to FIG. 6 . At step 600 , the process begins when the remote network controller 20 is powered up and initialized. At step 602 , the process initialization module 62 is invoked (described below with reference to FIG. 7 ). At step 604 , the event handler and multithreading dispatcher 60 waits for an event (e.g., receipt of inbound data) to occur. While the event handler and multithreading dispatcher 60 waits for an event to occur, mobile interface 24 may be placed in a “sleep” mode to conserve processor resources. At step 606 , once an event occurs, the event handler and multithreading dispatcher 60 determines if it is a recognized event. If the event handler and multithreading dispatcher 60 determines it is not a recognized event at step 606 , processing returns to step 604 . If, however, the event handler and multithreading dispatcher 60 determines that the event is a recognized event at step 606 , then processing continues at step 608 , where the event handler and multithreading dispatcher 60 determines if the data was received from the host data controller 22 .

[0091] At step 608 , if the event handler and multithreading dispatcher 60 determines the data was received from the host data controller 22 , the event handler and multithreading dispatcher 60 invokes the inbound data event handler 66 , at step 614 (described below with reference to FIG. 9 ) and processing continues at step 604 . If at step 608 the event handler and multithreading dispatcher 60 determines that the data was not received from the host data controller 22 , then the event handler and multithreading dispatcher 60 determines whether the data was received from the service interface 30 at step 610 .

[0092] If the event handler and multithreading dispatcher 60 at step 610 determines that the data was received from the service interface 30 , then at step 616 the outbound data event handler 68 is invoked (described below with reference to FIG. 10 ) and processing returns to step 604 . If the event handler and multithreading dispatcher 60 at step 610 determines that the data was not received from the service interface 30 , then at step 612 the event handler and multithreading dispatcher 60 determines if there is a process termination request.

[0093] If, at step 612 , the event handler and multithreading dispatcher 60 determines there is a process termination request, then at step 618 , the process termination module 70 is invoked (described below with reference to FIG. 11 ). If, at step 612 , the event handler and multithreading dispatcher 60 determines that there is not process termination request, then processing continues at step 604 to wait for another event.

[0094] Referring now to FIG. 7 , there is illustrated an exemplary flow chart for indicating the process flow of the process initialization module 62 of FIG. 5 . At step 620 , the interprocess communications interface is setup. At step 622 , the operating environment parameters are parsed and processed. This includes the host data controller 22 parameters referenced in steps 626 , 632 and 634 below. At step 624 , memory is allocated for the session and other tables contained within the mobile interface 24 , which are used to control data flow and other operations. At step 626 , the host data controller 22 parameters are accessed. At step 628 , a path to the host data controller 22 port is opened. At step 630 , the host data controller 22 then is prevented from monitoring for an event from the remote device(s) 52 . Step 630 prevents erroneous transmissions that may arise if the host data controller 22 attempts to monitor a remote device 52 before the initialization process is complete. At step 632 , the host data controller 22 communication parameters are set. At step 634 , the communication parameters are downloaded to the host data controller 22 . After the initialization processes of steps 632 and 634 are completed, the host data controller 22 at step 636 is enabled to monitor the remote device(s) 52 . At step 638 , the entire initialization procedure is complete and processing returns to step 604 in FIG. 6 .

[0095] Referring now to FIG. 8 , there is illustrated an exemplary flow chart describing the logic flow of the mobile session manager 64 of FIG. 5 . At step 640 , the mobile session manager 64 handler is entered from the event handler and multithreading dispatcher 24 when remote data is detected. At step 642 , the remote identifier of the remote device 52 is looked up in a session table. At step 644 , the mobile session manager 64 determines if the remote identifier was found in the session table. If the mobile session manager 64 determines that the remote identifier was found, the address is returned from the session table at step 646 .

[0096] If the mobile session manager 64 does not find the remote identifier at step 644 , then at step 648 the mobile session manager 64 attempts to authenticate the remote identifier. At step 650 , the mobile session manager determines if the authentication is successful. If at step 650 the authentication is successful, then at step 656 the host data controller 22 is instructed to connect to the remote device 52 based on the remote identifier. After the host data controller 22 is connected to the remote device 52 , the appropriate service interface 30 is invoked at step 658 . At step 660 , processing is complete. If at step 650 , the authentication was not successful, the remote data is ignored at step 652 , and a null session table entry address is returned by the mobile session manager 64 .

[0097] Referring now to FIG. 9 , there is illustrated an exemplary flow chart of the processing steps of the inbound data event handler 66 of FIG. 5 . At step 662 , the inbound data event handler is invoked (from step 614 in FIG. 6 ). At step 664 , the remote identifier of the remote device 52 is checked against the session table. At step 666 , it is determined whether the inbound data event handler 66 found the remote identifier in the session table. If at step 666 , the remote identifier is not found in the session table, the data is ignored and processing continues at step 604 in FIG. 6 . If the remote identifier is found in the session table at step 666 , the data is sent to the service interface 30 at step 670 . Processing then continues at step 604 in FIG. 6 .

[0098] Referring now to FIG. 10 , there is illustrated an exemplary flow chart of the processing steps of the outbound data event handler 68 of FIG. 5 . At step 672 , the outbound data event handler is invoked (from step 616 , FIG. 6 ). At step 674 , the session table is checked for the outbound data remote identifier. At step 676 , it is determined if the outbound data event handler 68 found the remote identifier in the session table. If at step 676 , the remote identifier is not found in the session table, an error is logged and the data message is ignored. Processing then continues at step 604 in FIG. 6 . If the remote identifier is found in the session table at step 676 , the data is sent to the remote device 52 as a single packet at step 680 . Processing then continues at step 604 in FIG. 6 .

[0099] Referring now to FIG. 11 , there is illustrated an exemplary flow chart of the processing steps of the process termination module 70 of FIG. 5 . At step 682 , the process termination module 70 is invoked (from step 618 in FIG. 6 ). At step 684 , the process termination module 70 determines if there are any active remote sessions. If, at step 684 , it is determined by the process termination module 70 that there are no active sessions, then at step 686 all files are closed and the mobile interface 24 terminates. If, however, it is determined by the process termination module 70 that there are active sessions, then at step 688 all of the active sessions are issued a disconnect request. At step 690 , the process termination module waits for all active sessions to terminate. Once all active sessions have terminated at step 690 , then all files are closed and the mobile interface 24 terminates at step 686 .

[0100] Referring now to FIG. 12 , there is illustrated an exemplary flow chart of the processes associated with the host data controller interface module 72 of FIG. 5 . The host data controller interface module 72 consists of a number of discrete functions (e.g., Initialize, Command, Send Data, and Receive Data) which are called when needed by the mobile interface 24 and share common information about the host data controller 22 . The host data controller interface module 72 may access the host data controller 22 via a serial communications port which is assigned to the mobile interface 24 and remains fixed when the remote network controller 20 is in operation.

[0101] A host data controller 22 initialize routine begins at step 692 . The initialization routine may be initiated in accordance with step 602 (see FIG. 6 ) and steps 632 and 634 (see FIG. 7 ). At step 694 , the serial communications port is accessed and setup. Thereafter, at step 696 , the port handle and status is saved to be used by other processes within the host data controller interface module 72 .

[0102] A host data controller 22 command routine begins at step 698 . The command routine may be initiated upon the occurrence of a recognized event (see, e.g., step 604 in FIG. 6 ) so that the appropriate control or operation commands may be sent to the host data controller 22 . At step 700 , the host data controller 22 is placed into a command mode. At step 702 , a command (e.g., disconnect or receive) is issued to the host data controller 22 based on the event that is recognized. At step 704 , the host data controller interface module 72 awaits a confirmation of acceptance of the command from the host data controller 22 . At step 706 , the result of the command is returned to the host data controller interface module 72 .

[0103] A host data controller 22 send data routine begins at step 708 and may be initiated from step 680 in FIG. 10 . The send data routine is initialized so that data may be sent to the appropriate remote device 52 . First, the physical identification of the remote device 52 is determined at step 710 . Thereafter, the data to be sent to the remote device 52 is placed into a packet at step 712 , and sent to the host data controller 22 at step 714 .

[0104] At step 716 , a host data controller 22 receive data routine is initiated in accordance with step 670 in FIG. 9 . The receive data routine is initiated so that data from the remote device 52 may be received by the remote network controller 20 . At step 718 , data is accumulated within the host data controller 22 receive data routine (see, FIG. 12 , step 716 ) until a full packet of information is received. Thereafter, at step 720 , the packet is identified as either session oriented or monitor oriented data. The identified data packet is then returned, at step 722 , to the mobile interface 24 and sent to the wired communication network 10 via the remote network controller 20 .

[0105] Referring now to FIG. 13 , in accordance with an aspect of the present invention, there is illustrated a block diagram of the basic components of the host data controller 22 (see, e.g., FIG. 2 ) of the present invention. The host controller 22 may be physically connected external to the remote network controller 20 via the mobile interface 24 . The host data controller 22 is specifically designed to convert the radio infrastructure 56 protocol to the internal protocol of the remote network controller 20 . Typically, one host data controller 22 may be connected to each mobile interface 24 ; however, one or more host data controllers 22 may be connected for redundancy and greater reliability.

[0106] As shown in FIG. 13 , the host data controller 22 may comprise an RF communications interface module 80 , a remote network controller communications interface module 78 , and a configuration and monitoring module 82 . The host data controller 22 may comprise any combination of hardware and software to perform the functions described herein. For example, the host data controller 22 may comprise a commercially available processor or multi-processor with overlying application software. The software running in the host data controller 22 may be written in Z80 or other appropriate high-level language (e.g., Pascal). The host data controller 22 may also contain a plurality of serial ports for communicating with other devices.

[0107] The remote network controller communications interface module 78 is connected to the mobile interface 24 of the remote network controller 20 and is responsible for sending and receiving data to and from the remote network controller 20 . A subsystem port 76 (e.g., an RS-232 adapter) may be used to connect the remote network controller communications interface module 78 to the mobile interface 24 of the remote network controller 20 . If the host data controller 20 is connected to more than one remote network controller, then additional subsystem port connection(s) may also be provided to connect to the interface module 78 to the additional remote network controllers. The remote network controller communications interface module 78 sends health and status information regarding the host data controller 22 to the mobile interface 24 . This information informs the remote network controller 20 that the host data controller 22 is operational and accepting data.

[0108] The configuration and monitoring module 82 is specific to the type of radio infrastructure 56 employed. Software parameters, such as the number of subsystem ports, how often to send health and status requests, and a list of mobile data controllers 54 to which the host data controller 22 can communicate, may be set and stored in the configuration and monitoring module 82 . The configuration and monitoring module 82 can also accumulate statistics which are passed to the mobile interface 24 .

[0109] In order to diagnose potential system errors in the host data controller 22 , the remote network controller 20 may test and analyze the host data controller 22 over a diagnostic port (not shown) to determine a cause of the system failure or error. The diagnostic port may be used not only to determine if the host data controller 22 is operational, but also to configure software parameters particular to the type of radio infrastructure 56 . These parameters can be changed to communicate with a different radio infrastructure 56 type as necessary.

[0110] The RF communications interface module 80 is responsible for sending and receiving the radio-frequency transmissions. The RF communications interface module 80 is specific to the radio infrastructure 56 in use and is connected to the radio infrastructure 56 by a communication line 57 . Again, because the host data controller 22 is designed to integrate with an existing radio infrastructure 56 , each host data controller 22 is software configured to work with many different types of radio infrastructure 56 protocols for flexibility. The host data controller 22 may be designed to be plugged into the remote network controller 20 , connecting to the mobile interface 24 , and can simply be exchanged with a different host data controller 22 , or reprogrammed depending on the radio infrastructure 56 employed. Host data controllers 22 may be configured so as to be compatible with, for example, conventional point-to-point radio systems, conventional repeater-based radio systems, LTR Trunking, Motorola Trunking, Ericsson (EDACS) Trunking—Voice Path, EDACS RDI Trunking—Data Path, and EDACS IMC Voice Path radio infrastructures.

[0111] Referring to FIG. 14 , there is illustrated a block diagram of the components comprising the service interface 30 (see FIG. 2 ) of the present invention. The service interface 30 is responsible for communicating to and from the wired communication network 10 . The service interface 30 is concerned only with the software level protocols of the wired communication network 10 . The hardware interface to the wired communication network 10 is accomplished by a known network control card, such as an Ethernet controller or a Token-Ring controller.

[0112] The number of service interface 30 connections to the wired communication network 10 is dictated by the type of wired communication network 10 . If the wired communication network 10 uses asynchronous data transfer, there will be one service interface 30 for every entry point, e.g., serial port, into the wired communication network 10 . In a local area network (LAN) environment, each service interface 30 may handle a variety of different network addresses. A different service interface 30 may be used for each type of wired communication network 10 .

[0113] As shown in FIG. 14 , the service interface 30 may include an event handler and multithreading dispatcher 90 , a process initialization module 92 , an inbound data event handler 94 , an outbound data event handler 96 , a process termination module 98 and a wired network interface module 100 . The event handler and multithreading dispatcher 90 may contain high-level logic and be used to control the overall execution flow of the service interface 30 . The process initialization module 92 acquires resources and establishes the operation environment of the service interface 30 process. The inbound data event handler 94 responds to signals from the interprocess communication manager 28 that inbound data is available and preprocess session control information. The inbound data event handler 94 may also handle asynchronous timer events. The outbound data event handler 96 is provided to respond to signals from wired communication network interface module 100 that outbound data is available or that a timer event has occurred. The process termination module 98 functions to release previously-acquired resources and terminate the service interface 30 process gracefully. The wired communication network interface module 100 handles low-level interaction with the associated wired communication network transport mechanism, i.e., communication protocol, being used.

[0114] An exemplary process flow of the event handler and multithreading dispatcher 90 (see FIG. 14 ) of the present invention will now be described with reference to FIG. 15 . At step 800 , the process begins when the service interface 30 is powered up and initialized. At step 802 , the process initialization module 92 is invoked (described below with reference to FIG. 16 ). At step 804 , the event handler and multithreading dispatcher 90 waits for an event to occur in response, e.g., to network or remote device activity. While the event handler and multithreading dispatcher 90 waits for an event to occur, the service interface 30 may be placed in a “sleep” mode to conserve processing power. At step 806 , once an event occurs, the event handler and multithreading dispatcher 90 determines if it is a recognized event. Recognized events may include Initialize, Send Data, Receive Data and/or Terminate. If the event handler and multithreading dispatcher 60 determines it is not a recognized event at step 806 , then processing returns to step 804 . If the event handler and multithreading dispatcher 90 recognizes the event at step 806 , then processing continues at step 808 , where the event handler and multithreading dispatcher 90 determines if the data was received from the host communication network 10 .

[0115] At step 808 , if the event handler and multithreading dispatcher 90 determines the data was received from the host wired communication network 10 , the event handler and multithreading dispatcher 90 invokes the inbound data event handler 94 , at step 814 (described below with reference to FIG. 17 ) and, thereafter, processing continues at step 804 . If at step 808 the event handler and multithreading dispatcher 90 determines that the data was not received from the host wired communication network 10 , the event handler and multithreading dispatcher 90 then determines if the data was received from the mobile interface 24 at step 810 .

[0116] If the event handler and multithreading dispatcher 90 determines at step 810 that the data was received from the mobile interface 24 , then at step 816 the outbound data event handler 96 is invoked (described below with reference to FIG. 18 ) and, thereafter, processing continues at step 804 . If the event handler and multithreading dispatcher 90 at step 810 determines that the data was not received from the mobile interface 24 , then at step 812 the event handler and multithreading dispatcher 90 determines if there is a process termination request.,

[0117] If, at step 812 , the event handler and multithreading dispatcher 90 determines there is a process termination request, then at step 818 the process termination module 98 is invoked (described below with reference to FIG. 19 ). However, if at step 812 the event handler and multithreading dispatcher 90 determines that there is not process termination request, then processing returns to step 804 to wait for another event.

[0118] Referring now to FIG. 16 , there is illustrated an exemplary flow chart describing the process flow of the process initialization module 92 (see, e.g., FIG. 14 ) of the present invention. At step 820 , the interprocess communications interface is setup when the service interface 30 is started or powered up. At step 822 , the operating environment parameters are parsed and processed (i.e., the parameters of the operating environment are processed individually). At step 824 , any resources required (e.g., memory) are acquired. Thereafter, at step 826 , the wired communication network interface module 100 is invoked (see FIGS. 20 - 24 discussed below). As discussed below, the wired communication network interface module 100 may include several procedures associated with initializing the connectivity with the wired communication network 10 , reading data from the wired communication network 10 , writing data to the wired communication network 10 , and terminating connectivity with the wired communication network 10 . In accordance with an aspect of the present invention, a unique set of procedures may be provided by the wired communication network interface module 100 for each type of wired communication network 10 . For example, a unique set of procedures may be provided for networks utilizing transparent asynchronous communications, TCP/IP stream sockets, Vehicle Location Reporting Facilities, Bidirectional Messaging Facilities, or Credit Card Verification Facilities.

[0119] After the wired communication network interface module 100 is invoked, the results of the previous operations performed at step 826 are sent at step 828 to the mobile interface 24 . At step 830 , it is determined by the process initialization module 92 if the wired communication network interface module 100 was successfully invoked at step 826 . If it is determined at step 830 that the wired communication network interface module 100 was successfully invoked, then the initialization is complete at step 832 , and processing returns to step 804 in FIG. 15 . If, however, it is determined at step 830 that the wired communication network interface module was not successfully invoked, then the service interface 30 is terminated at step 834 .

[0120] Referring now to FIG. 17 , there is illustrated an exemplary flow chart of the processing steps for the inbound data event handler 94 (see, e.g., FIG. 14 ) of the present invention. At step 836 , the inbound data event handler is invoked (from step 814 in FIG. 15 ). At step 838 , the data portion of the message sent by the wired communication network 10 is extracted. At step 840 , the service interface 30 requests a packet of data from the mobile interface 24 . At step 842 , after the packet is accepted by the service interface 30 , data is sent to the appropriate destination via the wired communication network 10 . The inbound data event handler 94 then waits for a disconnect request at step 844 . If the inbound data event handler 94 receives a disconnect request at step 844 , then a disconnect command is sent to the mobile interface 24 at step 846 . Processing then continues at step 804 in FIG. 15 . If, however, the inbound data event handler 94 does not receive a disconnect request at step 844 , then the request received is ignored at step 848 and, thereafter, processing then continues at step 804 in FIG. 15 .

[0121] Referring now to FIG. 18 , there is illustrated an exemplary flow chart of the processing steps for the outbound data event handler 96 (see FIG. 14 ) of the present invention. At step 850 , the outbound data event handler is invoked (from step 816 in FIG. 15 ). At step 852 , the outbound data event handler 96 determines if there is a request (e.g., a disconnect request from the wired communication network 10 or the remote device 52 ). If there is a request, then processing continues at step 856 . However, if there is presently not a request, then at step 854 the outbound data from the network 10 is sent to remote device 52 via the mobile interface 24 . At step 865 , the outbound data event handler 96 then determines if a disconnect request has been received. If the outbound data event handler 96 receives a disconnect request at step 856 , then a disconnect command is sent to the mobile interface 24 at step 860 by the interprocess communication manager 28 (see, e.g., FIG. 2 ). Processing then continues at step 804 in FIG. 15 . If, however, the outbound data event handler 96 does not receive a disconnect request at step 856 , then the request received is ignored at step 862 and processing then continues at step 804 in FIG. 15 .

[0122] Referring now to FIG. 19 , there is illustrated an exemplary flow chart of the processing steps for the process termination module 98 (see FIG. 14 ) of the present invention. At step 864 , the process termination module 98 is invoked (from step 818 in FIG. 15 ). At step 866 , the wired communication network interface module 100 connection is closed. Thereafter, at step 868 , the processes associated with the service interface 30 are terminated.

[0123] Referring now to FIGS. 20 - 24 , there are illustrated exemplary flow charts of the various processes that may be performed by the wired communication network interface module 100 of the present invention. The wired communication network interface module 100 may consist of a number of discrete functions which provide the service interface 30 with a uniform means of communicating with various host computer networks, irrespective of the communication protocols of the wired communication network 10 . All protocol and other feature-specific communications translation and handling is performed at the wired communication network interface module 100 . The wired communication network interface module 100 may be designed for networks utilizing different implementations, such as transparent asynchronous communication, Hayes compatible communication, TCP/IP stream socket, Bidirectional Messaging Facilities, File Transfer Facilities, SNA Protocol Enveloping, Vehicle Location Reporting Facilities, Credit Card Verification Facilities, and Harris DNP 3.0 Frame Relay. As noted above, a unique set of procedures may be provided by the wired communication network interface module 100 for each type of wired communication network 10 . Examples of several of these sets of procedures are provided below.

[0124] Referring now to