Apparatus and method for intelligent routing of data between a remote device and a host system
An apparatus and method is provided for transparent communication between a remote or mobile device and a fixed communication host network. The apparatus and method may include a remote network controller that logically resides between the host network and the existing infrastructure(s) that are used to provide communications network contact with one or more remote devices. The remote network controller is connected to the host communication network as a protocol-appropriate communications controller so that remote devices are indistinguishable to the host network from the locally-attached devices. Each remote device may be provided with an asynchronous serial data interface to communicate with a mobile data controller. The mobile data controller, in combination with the remote network controller, provides end-to-end data communication such that incompatible protocols are transparent to the remote device and host communication network. A router may be provided which selects a communications network in accordance with user configured parameters. The router communicates over a plurality of incompatible networks and is capable of using a variety of different protocols. Switching between the plurality of incompatible networks is transparent to the remote device and host communication network.
Latest PADCOM, Inc. Patents:
The present application is a Continuation of application Ser. No. 10/898,283, filed Jul. 26, 2004, which is a Continuation of application Ser. No. 10/164,581, filed Jun. 10, 2002, (now U.S. Pat. No. 6,826,405), which is a Continuation of application Ser. No. 08/932,532, filed Sep. 17, 1997 (now U.S. Pat. No. 6,418,324), which is a Continuation-in-Part of U.S. patent application Ser. No. 08/456,860, filed Jun. 1, 1995 (now U.S. Pat. No. 5,717,737), the contents of which are expressly incorporated by reference herein in their entireties.
BACKGROUND OF THE INVENTION1. Field of Invention
The present invention relates to the transportation of data through dissimilar communications media. More particularly, the present invention relates to an apparatus and method for transporting data between a remote mobile or fixed terminal device and a host system over multiple, dissimilar communications media. The communications media over which the data is transported include wireless data links, wired data links or a combination of wireless and wired data links which are selected based upon a set of preference metrics.
2. Background Information
The ability to transport data between mobile and/or fixed terminal devices and host computer systems have been generally available for many years. Networks designed to transport this data currently exist in a wide variety of wireless and wired network architectures. Both apparatus and method exists for transporting data through multiple, similar media types as well as the automatic selection of alternate communication paths based upon a plurality of preference metrics.
Often, when multiple networks are available from a common location such as a vehicle, great benefit may be derived by allowing uniform communications through all available networks. Certain networks may perform better for bulk data transfers where another may perform interactive messaging in an optimal fashion. One network may be preferable because of its low cost but an alternate, more expensive network may be acceptable as a backup if the low-cost network is unavailable.
Other examples include U.S. Pat. No. 5,412,375, to WOOD, which discloses a system for selecting one of a plurality of interfaces to a single wireless communications system in accordance with the capabilities of a subscriber unit and the capabilities of a base unit. A list of air interface capabilities of the subscriber unit and the base unit are compared by a controller to determine a compatible interface. As disclosed in WOOD, the plurality of air interfaces include Analog Mobile Phone System (AMPS), Time Division Multiple Access (TDMA) and Code Division Multiple Access (CDMA). While the WOOD system does select from one of a plurality of interfaces which may be applicable for data communication, the routing decision is based on the capabilities of the endpoints rather than the preference metrics of the transporting networks. The endpoint devices, in this case, must be aware of the peculiarities of the wireless environment.
U.S. Pat. No. 5,420,574, to ERICKSON et al., discloses a subscriber unit attached to a trunked mobile radio having a data input. The mobile radio communicates both voice and data message formats over a wireless network to a base station via channels that are allocated by a trunked data controller which is connected to a host network. Channel states and communication parameters are set in accordance with the type of information (e.g., voice or data) that is being transmitted or received. While the ERICKSON et al. system dynamically switches between incompatible message formats without the intervention of the endpoint devices, only a single data path is provided. In addition, the incompatibility of the two alternate paths arises from a difference in message formats rather than the use of independent, incompatible networks.
Further, the transportation of data through alternate, incompatible communications media is a problem that does not have a uniform solution in the art. This problem is exacerbated in wireless communication networks where protocols, timing and other incompatibilities render an otherwise acceptable level of service inadequate. Attempts to provide data links through incompatible networks have suffered from the same obstacles that hindered data communications prior to open standards becoming widely accepted, i.e., proprietary protocols visible to the endpoint terminal devices make the devices inflexible and expensive and the interoperation of similar devices with incompatible networking components is difficult and complex.
Networks may be interconnected by routers which operate at the network level and convey messages between compatible networks. Routers make logical decisions about the pathway through which data is to be directed in the networks based upon a variety of preference metrics. A router is generally implemented as an autonomous device with multiple connections to the networks through which data is to be routed. Routers operate at the network layer and can recognize and manage protocols and multiple connections to networks. Routers usually operate in accordance with the address provided by the particular protocol of the network, and normally provide routing between and through networks utilizing the same network protocol and can route between networks that use different data-link layers, such as Ethernet, Token-Ring, Serial PPP, etc. Another type of router includes two routers loosely-coupled through a protocol-neutral data-link, where the linked routers are considered as a single “virtual” router.
Dissimilar networks may be connected by gateways which are devices that interconnect two or more dissimilar networks. A gateway differs from a router in that the endpoint terminal devices may implement a dissimilar or incompatible protocols. Gateways often perform specific protocol conversions at the layers above the network layer to move data from one type of network to another. In this regard, the Open Systems. Interconnection (OSI) model includes seven “layers” to provide communications between heterogeneous (i.e., incompatible) systems. The layers, from lowest to highest, are: the physical layer, the data link layer, the network layer, the transport layer, the session layer, the presentation layer, and the application layer. Each of the layers performs a specific task in transporting data between two or more entities. Such a layered structure is shown in The TCP/IP Companion, by Martin R. Arick, Wiley-QED, pp. 18-19.
U.S. patent application Ser. No. 08/456,860, to DOVIAK et al., for example, discloses a system in which a distant mobile or fixed terminal device transports data through a plurality of wireless network to an endpoint which may or may not implement the same network protocol as the distant device. However, while the DOVIAK et al. system is capable transmitting data over a plurality of dissimilar wireless communications networks, the system does not automatically transmit data through differing ones of a plurality of dissimilar networks in accordance with preference metrics to reach the data-link endpoints. Thus, the system does not automatically provide redundant or alternate pathways through which data may be delivered.
U.S. Pat. No. 5,537,220 to EZUMI et al., discloses a portable facsimile apparatus provided with a capability to communicate over a plurality of communications lines. As disclosed in EZUMI et al., the facsimile machine may communicate over telephone lines or a mobile communication unit. A NCU (controller) is provided within the facsimile machine to discriminate whether the facsimile machine is connected to the telephone line or to the mobile communication unit. The NCU functions to adjust the data rate, and transmitting and receiving signal levels based on which communication system it is communicating. Although this concept may be extended to a generic protocol-neutral data networking environment, the EZUMI et al. system provides for the selection of only one single path to the exclusion of other, possible viable path based solely on which link is plugged into the NCU. Further, the EZUMI et al. system does not switch communication paths within the boundaries of a communication session thereby further limiting its usefulness in a connectionless, packet data environment such as a TCP/IP network.
U.S. Pat. No. 5,602,843, to GRAY, discloses a PBX-based integrated telecommunications system having a wired subsystem connected to wired terminals, and a wireless system for connecting to mobile terminals. A controller is provided which manages base stations and communicates to wireless handsets. When communicating to a handset, the controller determines which base station is in communication with the handset and directs the base station to send packet-based information to that handset. A separate PBX controller is provided to communicate with the wired terminals. The PBX controller includes a proximity sensor to detect wireless handsets such that when a handset is detected in proximity to a wired terminal, messages are forwarded to the wired terminal rather than the wireless handset. While the GRAY system dynamically selects the route to a terminal device based upon a preference metric (wireless proximity), the alternate routing technique does not address transporting data between the same two endpoints. In addition, GRAY provides no means to provide alternate path routing for a terminal device through either the wireless or wired handsets.
U.S. Pat. No. 5,452,471, to LEOPOLD et al., discloses a communication system having a primary and one or more subordinate communication systems. In the illustrated embodiment, the primary communication system is a satellite-base communication system having the widest area of coverage. Each of the satellites within the system defines a cell area which moves as the orbiting satellites move. The secondary and tertiary communications systems are disclosed as terrestrial based, stationary systems having base stations fixed near the surface of the earth (e.g., fixed to a building), where each subordinate system has an increasingly smaller region of coverage. The secondary and tertiary systems include a controller located at a monitoring location within each region. Each of the communications systems includes a link to a central office to enable communications over the public switched telephone network. The LEOPOLD et al. communication systems and mobile subscriber units operate within one frequency spectrum, however, the primary and secondary communication systems operate together by using orthogonal channels to prevent interference. In addition, when communicating with secondary systems, the mobile subscriber unit transmits at a relatively low power such that the primary system will not receive the transmission. The mobile subscriber unit is programmed to utilize the communication system having the smallest area of coverage such that if the subscriber unit has three communications systems available, the subscriber unit will utilize the tertiary communications system (i.e., the system having the smallest area of coverage) based on a designed assumption that the more subordinate the communication system is, the higher the capacity of the system. While the system of LEOPOLD et al. dynamically selects a route based upon a set of preference metrics such that the terminal endpoints are unaware of the routing selection, a common data-link protocol is required throughout all possible associated networks. In addition, the wireless frequencies employed must be derived from a continuous, compatible set of frequencies which prevents the device from selecting among inherently incompatible networks.
Despite the teachings of these prior attempts, users of mobile or fixed wireless data communications are provided with systems of limited capacity and flexibility when routing data through more than one network. In addition, such systems require special hardware and/or software developed for and compatible with the networks, which may require additional training of support personnel and end-users. Further, users of wireless mobile data communication services are provided with only a limited ability to control costs associated with sending and receiving data to and from remote devices, and are limited in their hardware and software design implementations. In previous teachings, the candidate networks must be compatible with one another at either the network or the data-link level. Thus, routing data through inherently incompatible networks such as Cellular Digital Packet Data (CDPD) and Ericsson EDACS is not possible as these are incompatible at both the data-link and network levels. Moreover, known systems do not allow a customer to use existing RF wireless infrastructures, including existing hardware and software, with only minor modifications needed to transport data from a mobile device to a host computer network. In addition, past attempts do not permit wireless data communications in a manner that is transparent to the remote device. Further, prior systems do not provide the flexibility to users such that a plurality of different remote devices may communicate with the wired host network irrespective of the radio infrastructure and transmission protocol employed. Such features, without the above-noted drawbacks, would be highly desirable to provide flexibility and ease of use, and to give users of portable data devices greater control over their hardware and software design.
SUMMARY OF THE INVENTIONIn view of the foregoing, the present invention, through one or more of its various aspects, embodiments and/or specific features or sub-components thereof, is thus presented to bring about one or more objects and advantages, such as those specifically noted below.
A general object of the present invention is to provide an apparatus and method for transporting data from a remote, wireless device to a wired network. Another object of the invention is to provide a remote device with an interface to present data to the wired network through RF wireless communication.
More particularly, an object of the present invention is to provide an apparatus that resides between an existing wired communications network and an existing radio-frequency network to provide a wireless RF connection between a remote device and the wired network.
Another object of the present invention is to provide an apparatus and method for a completely transparent data path between a remotely located device and an existing wired network using a wireless RF communications link without either the remote device, or the wired network being aware that a wireless RF communications link is being employed.
Still another object of the present invention is to provide an apparatus and method for a completely transparent data path between a remotely located device and an existing wired network through a plurality of different wireless RF communications link protocols and a plurality of different wired networks protocols selected by the user.
Still another object of the present invention is to provide an apparatus which functions as a protocol-appropriate communications controller and makes remote devices indistinguishable from locally attached devices to a wired network.
According to one aspect of the present invention, an apparatus for transporting data between a remote device and a host communication network using a wireless communications link is provided. The apparatus comprises a mobile data controller connected to the remote device and the wireless communications link. The mobile data controller comprises a remote data conversion means for converting data to be transported between the remote device and the host communication network. The remote data conversion means converts the transported data between a remote device transmission format utilized by the remote device and a wireless link transmission format utilized by the wireless communications link.
The apparatus also comprises a network interface means for interfacing the host communication network with the wireless communications link. The network interface means comprises a wireless link conversion means for converting the transported data between the wireless link transmission format and a network interface format utilized by the network interface means; and a host network conversion means for converting the transported data between the network interface format and a host network format utilized by the host communication network.
The apparatus further comprises a means for transporting the transported data over the wireless communication in accordance with the wireless link transmission format, the wireless link transmission format and the host network format being incompatible. According to another aspect of the present invention, the network interface means comprises a remote network controller that logically resides on the host communication network and performs the functions of a network communication controller.
According to another aspect of the present invention, the apparatus for transporting data further comprises a plurality of network interface means connected by a local network and a synchronization means for synchronizing the transfer of information between the network interface means, the information comprising routing tables and health and status information.
According to the present invention a method of transporting data from a mobile device to a host network is provided. The remote device and a wireless communications link are connected by a mobile data controller, and the host communication network and the wireless communications link being interfaced by a network interface device.
The method includes the steps of: converting, at the mobile data controller, data to be transported between the remote device and the host communication network, the converting step converting the transported data between a remote device transmission format utilized by the remote device and a wireless link transmission format utilized by the wireless communications link; transporting the transported data over the wireless communications link in accordance with the wireless link transmission format; receiving, at the network interface device, the transport data from the wireless communications link; converting, at the network interface device, the transported data between the wireless link transmission format and a network interface format utilized by the network interface device, the wireless link transmission format and the host network format being incompatible; further converting, at the network interface device, the transported data between the network interface format and a host network format utilized by the host communication network; and forwarding the transported data to the host communication network in accordance with the host network format.
In a preferred embodiment, the transportation step further comprises determining wireless communications link selection criteria; dynamically selecting a wireless communications link from a plurality of incompatible wireless communications links in accordance with the selection criteria; and switching to the selected wireless communications link. Afterwards, the following steps are continuously repeated: dynamically selecting a next wireless communications link from the plurality of incompatible networks in accordance with the selection criteria; determining whether to switch wireless communications links; and switching to the next wireless communications link in response to a result of the determination.
According to another aspect of the present invention, an apparatus for transporting data over a plurality of incompatible networks between a first device and a second device is provided. The apparatus comprises a system for determining network selection criteria. In addition, the apparatus comprises a selection system for dynamically selecting a network from the plurality of incompatible networks in accordance with the network selection criteria and a switching system for switching to the selected network to use for data transport.
According to another aspect of the present invention, the apparatus transports data via a plurality of protocols over a plurality of incompatible networks in which the transportation of data is transparent to the first and second devices and to an end user. The protocols may include but are not limited to Internet Protocol (IP) and transparent protocol.
According to another aspect of the present invention, the apparatus for transporting data further comprises a system interfacing protocolized data into a plurality of incompatible networks using different protocols.
According to another aspect of the present invention, the switching system switches networks during the time between the transport of consecutive data packets.
According to another aspect of the present invention, the system for determining network selection criteria uses two classes of parameters to determine the next network to use for transport of data.
According to another aspect of the present invention, the selection system further determines a next network to switch to from the plurality of incompatible networks in accordance with the network selection criteria, when the selected network becomes unavailable. In addition, a monitoring system is provided which monitors the availability of the incompatible networks to determine whether the next network is available for data transport.
The above-listed and other objects, features and advantages of the present invention will be more fully set forth hereinafter.
BRIEF DESCRIPTION OF THE DRAWINGSThe present invention is further described in the detailed description which follows, by reference to the noted plurality of drawings by way of non-limiting examples of preferred embodiments of the present invention, in which like reference numerals represent similar parts throughout the several views of the drawings, and wherein:
Referring now to the accompanying drawings,
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.
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.
Referring now to
As shown in
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.
As further illustrated in
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.
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 20 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.
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.
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.
Referring again to
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.
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.
The validation process of the outbound data depicted in
Referring now to
As shown in
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.
The process flow of the event handler and multithreading dispatcher 60 will now be described with reference to
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
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
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
Referring now to
Referring now to
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.
Referring now to
Referring now to
Referring now to
Referring now to
A host data controller 22 initialize routine begins at step 692. The initialization routine may be initiated in accordance with step 602 (see
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
A host data controller 22 send data routine begins at step 708 and may be initiated from step 680 in
At step 716, a host data controller 22 receive data routine is initiated in accordance with step 670 in
Referring now to
As shown in
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.
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.
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.
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.
Referring to
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.
As shown in
An exemplary process flow of the event handler and multithreading dispatcher 90 (see
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
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
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
Referring now to
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
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
At step 908 a data read operation begins. The data read routine may be invoked by the outbound data event handler 96 at step 850 (see
At step 920, a write data routine is started. The write data routine may be initiated by the inbound data event handler 94 at step 836 in
At step 924, a terminate routine is initiated. The terminate routine may be initiated in accordance with a terminate request at step 818 in
Referring now to
At step 940 a data read operation begins. The data read routine may be invoked the outbound data event handler 96 at step 850 (see
At step 946, a write data routine is started. The write data routine may be initiated by the inbound data event handler 94 at step 836 in
At step 950, a terminate routine is initiated. The terminate routine may be initiated in accordance with a terminate request at step 818 in
Referring now to
At step 966 a data read operation begins. The data read routine may be invoked by the outbound data event handler 96 at step 850 (see
At step 972, a write data operation is started. The write data routine may be initiated by the inbound data event handler 94 at step 836 in
At step 982, a terminate routine is initiated. The terminate routine may be initiated in accordance with a terminate request at step 818 in
Referring now to
At step 992 a data read operation begins. The data read routine may be invoked by the outbound data event handler 96 at step 850 (see
At step 1002, a write data routine is initiated. The write data routine may be initiated by the inbound data event handler 94 at step 836 in
Referring to
Referring now to
At step 1026 a data read operation begins. The data read routine may be invoked the outbound data event handler 96 at step 850 (see
At step 1034, a write data operation is started. The write data routine may be initiated by the inbound data event handler 94 at step 836 in
At step 1044, a terminate routine is illustrated. The terminate routine may be initiated in accordance with a terminate request at step 818 in
Referring now to
In accordance with the present invention, the mobile data controller 54 may be implemented by any combination of hardware and software. For example, the mobile data controller 54 may comprise a commercially available processor with overlying software and random access memory. The software running in the mobile data controller 54 may be written in Z80 or other appropriate processor-based (i.e., native) assembly language and configured to the specific radio infrastructure 56. The software may specify the various voltage levels and logic signals necessary to communicate via the RF communications infrastructure 56. As noted above, the mobile data controller 54 may translate and pass any protocols associated with the wired communications network 10 to and from the remote device 52 to make it appear to the wired communication network 10 that the remote device 52 is locally-attached.
The mobile data controller 54 is configurable over the radio infrastructure 56 configuration information may be input by an operator at the remote network controller 20 through the console interface 34 (see
As shown in
The configuration and monitoring module 104 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 host data controllers 22 to which the mobile data controller 54 can communicate, may be set and stored in the configuration and monitoring module 104. The configuration and monitoring module 104 can also accumulate statistics which are passed to the host data controller 22.
In order to diagnose potential system errors in the mobile data controller 54, an operator may be provided with the ability to field test and analyze the mobile data controller via an external diagnostic port 112 to determine a cause of the system error or failure. The diagnostic port 112 may be used not only to determine if the mobile data controller 54 is operational, but also can be used to configure software parameters to determine the type of the radio infrastructure 56. These parameters can be changed to communicate with a different type of radio infrastructure 56 as necessary.
The RF communications interface module 106 is responsible for sending and receiving the data via radio-frequency (RF) transmission. The RF communications interface module 106 is specific to the radio infrastructure 56 used, and is connected to the radio infrastructure 56 through a communication line 110. Because the mobile data controller 54 is designed to integrate with an existing radio infrastructure 56, each mobile data controller 54 may be software configured, for purposes of flexibility, to work with many types of radio infrastructure 56 protocols. The RF communications interface module 106 may also send health and status information regarding the mobile data controller 54 to the host data controller 22. This information may inform the remote network controller 20 that the mobile data controller 54 is operational and the remote device 52 is accepting data.
According to the present invention, the RF communication interface module 106 may include a commercially available modem (not shown). The modem may be selected depending on the data rate(s) of the communication line 100 and the radio infrastructure 56. More than one modem may be provided if multiple data rates are required. Optionally, the modem can be implemented using a Digital Signal Processing (DSP) chip and associated software. The DSP chip can be a commercially available programmable signal processing chip. In such a case, the DSP implementation will allow a single modem to be changed (e.g., by uploading new parameters to the DSP software) in order to communicate with a plurality of different types of radio infrastructures 56 having distinct protocols and data rates.
Similar to the host data controllers 22, the mobile data controllers 54 may 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 based radio infrastructures 56.
Referring again to
The interprocess communications manager 28 may also pass information generated by the remote network controller 20, which is independent of the data and routing information. This information may include internal parameters and error detection codes. The interprocess communications manager 28 also interfaces with the control process module 26. The control process 26 may act as the “central hub” of the remote network controller 20. The control process 26 provides resource management, process management, session management, configuration management and system statistics management within the remote network controller 20.
As further shown in
Referring now to
The transparent communications module 122 is responsible for communicating with a terminal device, typically a Remote Telemetry Unit (RTU) located in the field, and accepts data from the RF communications module 126. As shown in
The RF communications module 126 is configured to communicate with the remote network controller 20 using whatever protocol is required for data transport over the radio infrastructure 56. The RF communications interface module 126 interfaces with the radio infrastructure 56 in a similar manner as previously described above with regard to the RF communications interface module 106. The RF communications interface module 126 accepts data from the transparent communications module 122 and delivers it to the radio infrastructure 56 for transmission to the remote network controller. The RF communications interface module 126 detects collisions with inbound RF data and restarts outbound transmissions. The RF communications interface module 126 performs error/retry functions and notifies the transparent communications module 122 of successes or failures.
The field service interface module 128 allows a technician to field test the remote gateway 120 and troubleshoot the remote gateway should a system error or problem arise. An external diagnostic port 112 connected to the field service interface module 128 may be provided for this purpose. The field service interface module 128 may interact with the configuration and health module 124 to query, set, and reset local configuration of the remote gateway 120.
The configuration and health module 124 may accept configuration information from the remote network controller 20 via the radio infrastructure 56 and adjust the operating parameters of the remote gateway 120 accordingly. The configuration and health module 124 may also monitor and determine if the RF communications module 126 has successfully transmitted a packet of information to the host data controller 22 by analyzing the data stream. If a packet of information has not been successfully transmitted, the configuration and health module 124 may direct the RF communications module 126 to resend the packet of information to the host data controller 22.
Referring now to
As shown in
According to an aspect of the present invention, two remote network controllers 140 may be linked by a local network 152 (see
There are two main implementations of this system according to the present invention. With the first implementation, only one of the remote network controllers 140 is operating at any given time. Should the operational remote network controller 140 fail, the other remote network controller 140 may immediately take its place. For example, if remote network controller “A” fails, then remote network controller “B” may be activated to take its place.
Under the second implementation, a distributed processing scheme is utilized and both of the remote network controllers 140 are operated at the same time. According to the distributed processing scheme, the processing load (e.g., event handling and data transfer) may be distributed among the operational remote network controllers 140. Should a particular remote network controller 140 (e.g., controller “B”) fail, the remaining operational remote network controller 140 (e.g., controller “A”) will handle the entire processing load.
The above-mentioned distribution of the processing load is generally a function of the radio infrastructure 56, and not the processing capacity of the remote network controllers 140. This is because performance increases are mainly based on the number of available communications channels, rather than the raw processing capability of the remote network controllers 140 attached to the wired communications network 10. For example, if the radio infrastructure 56 is a trunking radio network with five channels, it is possible for all five channels to be simultaneously allocated and used by the remote network controllers 140. On the other hand, if there is only one channel available in the radio infrastructure 56, then only one remote network controller 140 can access the radio infrastructure 56 at a time; as a result, no performance gain may be realized by employing multiple remote network controllers 140 when only limited channels are available.
As illustrated in
The subsystem synchronization process module 150 may be implemented through any combination of hardware and software and is responsible for keeping track of all routing tables and health and status information associated with both of the remote network controllers 140. Each subsystem synchronization process module 150 is connected to an interprocess communications manager 28′ of one of the remote network controllers 140 and may access all routing tables and health and status information with respect to the remote network controller from the interprocess communications manager. The health and status information and routing tables may be periodically updated based on the status of and events present at the remote network controller 140. The periodically updated health and status information and routing tables may then be shared with the other subsystem synchronization process module 150 via the local network 152 so that the tables and information associated with both of the remote network controllers 140 is maintained in each of the subsystem synchronization process modules 150. Since the tables and information are periodically updated, a synchronization routine may be provided so that the information and tables are sent to the respective subsystem synchronization process modules 150 at predetermined intervals. If a particular subsystem synchronization process module 150 does not send or receive the tables and information, or if a particular subsystem synchronization process module 150 sends information indicating that one of the remote network controllers 140 has malfunctioned, the other subsystem synchronization process module 150 may reroute any existing connections to the host data controllers 22′ and to the wired network 10 of the malfunctioning remote network controller 140 to the remaining operational remote network controller 140.
As further shown in
While the invention has been described with references to several exemplary embodiments, it is understood that the words which have been used herein are words of description and illustration, rather than words of limitation. Changes may be made, within the purview of the appended claims, without departing from the scope and spirit of the invention in its aspects.
For example, although
Referring now to
Referring now to
With reference to
An exemplary application running on the mobile device 52 is a mobile remote client application which provides the remote user with the capability to send and retrieve data from a fixed database server application. The data may consist of customer records which, for example, may be used by service personnel operating a fleet of vehicles to service customers scattered about a wide geographic area. In the exemplary application, the mobile client application may request customer records from the fixed database server, and display the records for viewing by mobile service personnel. The mobile client application may send updated records to the fixed database as the service personnel finish assigned tasks. The updated records may contain a service history, equipment upgrades, and repairs for each customer.
Another exemplary application running on the mobile device 52 may be a client application which retrieves a list of dispatched jobs to be performed by the service personnel during each day. The jobs may be uploaded to the remote mobile device 52 each morning and stored in another client application in the mobile device 52. As the service personnel change job locations, the status of each job may be updated to indicate a status, e.g., en route, arrived and finished with comments. The status may be sent from the application to the fixed home office, so a dispatcher at the home office is aware of the locations of service personnel in the field.
By way of non-limiting examples, the mobile device 52 may comprise a portable or laptop computer; a computer having an embedded Router 200; a terminal or terminal emulator; a data gathering device (e.g., a SCADA system or remote telemetry system for obtaining data from a remote location for forwarding to a central location for processing); a card-swipe reader device (e.g., credit/debit/bank cards) for use in a mobile billing application, such as a taxi or mobile food cart; a smart-card reader; a logging device, such as those used in a package delivery system or fleet; a device for reading bar-codes (e.g., for inventory control); and a remote application with data to send or to receive, from a fixed application or device (e.g., remote diagnostic tool). The above-noted applications are provided merely for exemplary purpose, and other applications and mobile devices 52 may be used with the Router 200 of the present invention.
Typically the device or Application 52 sends and receives data using a variety of protocols (e.g., Internet Protocol (IP)/transparent (via MDC 54)/ack-nack, etc.). The use of a variety of protocols provides for open transport of data throughout many networks, and in particular, networks which support open standards such as IP. However, many proprietary networks which require interface and/or protocol translation remain in use. In the Router 200 of the present embodiment, the function of interfacing with networks and protocol translation may be performed by the Network Interfaces 214A-D.
According to another aspect of the invention, other types of devices may be connected to the Network Interface 214. Such devices may be used for functions other than data and voice communication. By way of non-limiting examples, these devices may include Global Positioning System (GPS) receivers and application processors.
The Router Core 204 is a function which shuttles messages between the Application or Device 52 and the various Networks. In accordance with the present embodiment, the router Core 204 may control which network of a plurality of usable network messages are to travel over, and connect access ports (described below) to each Network and the Application or Device 52.
The Router Core 204 may also comprise a list of all possible “names” or “addresses” to which data may be sent, or from which data may be received. The local “names” or “addresses” of the Router Core 204 are stored in tables within a memory (not shown) of the Router Core 204. Thus, the Router Core 204 may serve as a communications “address book” for the Router 200 of the present embodiment. The Router Core 204 also checks all messages passing through, and decides, base on the address and/or name entries in the tables, if the message is relevant to the attached Application or Device 52, or to the fixed host (e.g., RNC 20). The address of the fixed host may be stored in the Router Core table as well. In accordance with the table entries, received messages may be determined to be valid or invalid. The Router Core 204 may also actuate the Switch 212 in accordance with the output of the decision process 206. The Switch 212 is actuated such that incoming and outgoing messages can be sent through the “current” network, as determined by the decision function 206 (to be described below).
The Switch 212 may comprise a message multiplexor, i.e., the Switch 212 performs a one-to-many function for in-bound messages (to the fixed hosts), and a “many-to-one” function for outbound messages (from the fixed host). As noted above, the appropriate network selection is made by the Router Core 204 in accordance with the output of the decision process 206. Messages travel through the Switch 212, the Router Core 204, and the current Network Interface 214.
Referring to
As a non-limiting exemplary hardware implementation, the Switch 212 may comprise an 80386EX microprocessor, running at 33 MHZ, 256 kilobytes of FLASH ROM, 512 kilobytes of static RAM, six asynchronous serial ports, two TTL-to-RS232 convertors interfacing with two of the six serial ports directly to compatible devices external to the Switch 212, and four internal TTL serial interfaces to internally-mounted daughter boards, which carry Network Interfaces 214A-D. Each Network Interface 214 mounted on a daughter, board may include a power supply for the Network Interface, a serial interface to the 80386EX microprocessor, and an interface to the outside network. The outside network may be a radio, a LAN, an antenna (for internally-mounted radios in the Network Interface 214), or other device accepting or supplying data from/to the Router 200.
The Switching function of the Switch 212 is provided by each serial Network Interface port at the 80386EX microprocessor, and the software residing in FLASH ROM. The software logic determines which Network Interface to use for transmission and receipt of data. The decision is implemented in the Switch, by selecting a physical serial port (and therefore which Network Interface) is to be used as the current Network. The Decision software in the FLASH ROM instructs the microprocessor to send the data to a specific serial port (which is mapped to specific physical addresses within the address range of the 80386EX microprocessor). The microprocessor then constructs the next message in the message buffers in RAM, and sends the message through the specific serial port which is designated as the “current Network” Interface port. The data then goes to the Network Interface (e.g., network interface 214A) connected to that specific serial port and on to the Network infrastructure. Received data is input to the Network Interface (e.g., network interface 214B which may be set to the “current Network” serial port) and the microprocessor, where the received data is processed by the microprocessor. In accordance with an aspect of the present invention, messages which are received through Network Interfaces which are not designated as the “current Network” are ignored.
The Network Interfaces 214A-D are devices which present data to, or obtain data from the radio operating at the various R.F. Network frequencies, bandwidths, and modulations. The Network Interfaces 214A-D may provide a port through which messages pass, to and from the Switch 212. The messages are typically in the form of a sequence of serial digital bits. The Network Interfaces 214A-D also may provide a modulator/demodulator function which transforms the digital data into an analog form which may be easily sent through the R.F. Network voicepath, based on characteristics of the assigned frequency band of the R.F. Network. The characteristics of analog transmissions are typically bandwidth (in Hertz, or cycles per second), noise present in the Network, and assigned frequency of the R.F. Network. Further, the Network Interfaces may interface with a radio, which may be included within the Network Interface 214, or may be mounted externally to the Router 200 (as shown in
Examples of Network Interface 214A-D include the MDC 54 and the NovaTel Wireless NRM-6812 Cellular Digital Packet Data (CDPD) modem. Where the network interface 214 comprises the MDC 54, the radio is mounted external to the MDC 54, whereas in the NovaTel example, the radio and the network interface are integrated into a single unit.
As noted above, the Network Interfaces 214 provide connections to various types of networks. These networks may be wired (for example Public Switched Telephone Network 58), or wireless (for example Cellular Digital Packet Data (CDPD)). The following non-limiting list includes networks that may be interfaced to the Router 200 by the Network Interfaces 214A-D: private voice radio including conventional and trunked radios (e.g., using MDC 54), Cellular Digital Packet Data (CDPD), Spread Spectrum (e.g., direct sequence and channel-hop), GSM, GPS receiver, satellite transponder, RDI (Ericsson) interface, AMPS, RAM Mobile (Mobitex), RS232, RS485, Angel (AT&T), Asynchronous Transfer Method (ATM), Integrated Services Digital Network (ISDN), public switched telephone network (PSTN (POTS) telephone network), Ethernet, Ardis, Personal Communications Services (PCS), and any other network which is either transparent or operates using a specific protocol.
The specific protocols to the above-listed networks are implemented in the Network Interfaces 214A-D. These protocols may be very different, and therefore incompatible with each other. Additionally, a translation device may be provided in each Network Interface 214 to translate between IP and the particular network protocol. By providing such a translation device, the Application or Device 52 can use IP data regardless of the particular network the Application or Device 52 is actually using.
Referring to
The Router Core 204 is responsible for making all routing decisions. For a given destination network address specified within a data packet or datagram received from one of the network interface drivers 215A-D, the most-preferred path will be selected and the data packet or datagram forwarded through the preferred network interface driver 215A-D. Routing decisions are generally based upon such metrics as network speed and interface availability. Other metrics such as destination network, time of day, type of data, etc. may also be incorporated into the routing decision. Further, routing decisions may be made at the packet level such that each individual packet of data may be transmitted and/or received on different networks in accordance with the user configured parameters 208.
Exemplary Network Drivers 215A-D may include an Ethernet Driver, a Token-Ring Driver, and a Serial PPP Driver. The Ethernet Driver provides a means for sending and receiving data through an Ethernet-type network. The function of the driver is to shield the Router Core from the details of network media access. The Token-Ring Driver provides a means for sending and receiving data through a Token-Ring-type network. The function of the driver is to shield the Router Core from the details of network media access. The Serial PPP Driver provides a means for sending and receiving data through a PPP-based serial data link. The function of the driver is to shield the Router Core from the details of network media access. Other drivers 215A-D may be provided to interface with other types of networks as necessary.
The Network Availability 210 (see also
The Network Availability 210 of each Network Interface 214 is determined in a manner specific to the particular interfaced Network. For example, if the Network is CDPD, the Network Availability 210 interrogates the network to determine if the Network Interface 214 is currently registered with the Network, and therefore active. Also, in the CDPD network, the Network Availability 214 determines if the Received Signal Strength Indication (RSSI) is sufficient to transmit relatively error-free data. For example, in the NovaTel CDPD Network Interface a RSSI of −100 dBm will provide for good data transmission qualities. Thus, if the Network Availability 210 function queries the NovaTel CDPD Network Interface for the RSSI, and the response is −110 dBm, then the signal is too weak for error-free transmission, and therefore cannot be used at this time. This information is passed to the Decision process 206 to determine if the “current Network” should remain the “current Network”, and if not, to determine what the “next Network” should be.
The User Configuration 208 block is used to define user configurable parameters by which the Router Core 204 selects the “current Network” and the “next Network”. The Router parameters may include the date and time (e.g., yr-mo-da, hh:mm:ss), and the Network Interface 214 installed in each of the internal slots of the Router 200. According to the present embodiment there are six internal slots to accommodate Network Interfaces to any of private voice radio using e.g., the MDC 54 and a variety of radios, both conventional and trunked; Cellular Digital Packet Data (CDPD), such as Sierra Wireless or NovaTel CDPD modems; spread spectrum, either direct sequence, or channel-hop, as Xetron Hummingbird spread spectrum modem; GSM, such as Ericsson serial GSM module; GPS receiver, such as Motorola VP Encore GPS receiver, or Trimble SVEE Six receiver; satellite transponder; RDI (e.g., Ericsson) interface, implemented via a software protocol module and quasi-RS232 interface to radio; AMPS; RAM Mobile (e.g., Mobitex); RS232 default and fixed for example in slots 1 and 2; RS485; Angel (e.g., AT&T); ATM; ISDN; PSTN; Ethernet; Ardis; PCS; any other network which is either transparent or operates using a specific protocol; and none. Although six slots are disclosed herein, other numbers of slots may be provided.
Other user configurable parameters include: the priority of each internal slot, (e.g., 1 to 6) where the slot with priority 1 is the default startup slot and Network; baud rate of each slot (a default rate may be set to 9600 bits per second, but may be configured to be any standard baud rate, divisible by 300, up to 115.2 kilo bits per second); cost per kilobyte per slot (e.g., $0.xx per kilobyte where the least costly slot that is available and highest priority will be default); protocol per slot (e.g., none, Point to Point (PPP), Serial Line Internet Protocol (SLIP), Hayes “AT” commands, transparent); slot mode, for example, transparent, PSTN, cellular, IP, receive only; slot name or address or phone number; slot to be used for diagnostics (e.g., default may be set to slot 2); slot muting to be used (e.g., none, PL, DTNF, other); number of retry transmissions per Network Interface (per slot) before declaration of Network Interface failure (e.g., 0-10); if slot Network Interface-needs to be configured before it can operate (e.g., y,n); slot to be used for remote display (e.g., default may be set to slot 2); slot to be used for Device or Application 52 (e.g., a connection to a mobile computer; default is slot 1); and frequency at which Network Availability 210 is checked (e.g., default may be set to five seconds). Other user configurable parameters may be introduced and configured as necessary.
The User Configuration 208 function provides the user with the capability to instruct the Router 200 how to select a particular Network. These metrics may include, but are not limited to: which Network is connected to which Router port, time of day and date, priority (switching sequence) of each Network, cost per packet of each Network, and preferred default Network.
On power up, the User Configuration 208 is checked to determine if it is current. If the User Configuration 208 is determined to be out of date, the end user is requested to input a configuration. The user is notified by blinking LEDs on the front panel or by a message sent to the mobile device 52. If the User Configuration 208 is determined to be current, no user input is requested.
Further, each Network is continuously evaluated for health and connectivity status. There are a number of parameters which are examined to determine this, including, but not limited to: Received Signal Strength Indication (RSSI), Clear to Send (CTS), Channel Clear/Channel Ready, and Transmit Grant.
The Decision process 206 continuously examines the User Configured parameters in the user configuration block 208, to determine the next Network to use, in case the current Network becomes unavailable to send or receive data. Such an unavailability may arise because the remote user (and consequently the Router 200) has moved beyond coverage of the Network, or because a problem has occurred with the current Network or the Network Interface 214.
After the Decision process 206 has determined the next Network to use, the decision process 206 queries the Network Availability 210. If the next Network is available, then the Decision process 206 updates the routing tables in the Router Core 204. The Router Core 204 will then actuate the Switch 212 to physically connect the next Network as the current Network.
The Decision process 206 uses the User Configuration 208 parameters defined above to determine the specific criteria for each slot, to be used when deciding if the current Network is to remain the current Network, and if not, what the next Network shall be. Once the decision process 206 has made a tentative decision to switch to another Network (i.e., the next network is to become the current network), it checks the Network Availability 210 to ascertain if the Network is actually installed, configured, on-line, and in good health. For example, if the current Network is configured as priority #3, and the Network Availability 210 of the priority #2 Network updates to, for example, “installed, configured, on-line, and in good health”, then the priority #2 Network becomes the next Network. The Decision process 206 will instruct the Switch 212 to switch the priority #2 Network to the current network. Should the Decision process 206 decide to change Networks, it conveys an instruction to the Router Core 204 by instructing the Router Core 204 what the next Network Interface 214 is to be.
The process of the Decision process 206 checking the User Configuration 208 and the Network Availability 210 continues indefinitely, and is described in detail in
Once it has been determined that all channels have been checked, at Step 322 it is determined whether any tables have been built. If no tables have been built, at Step 324 a configuration error is recognized and the processing stops. Tables may not have been built previously, e.g., if there are problems with the IP address, i.e., there was no destination address. If at Step 322 it is determined tables were already built, processing proceeds to Step 326 where all channels are initialized and data transportation begins via the first channel.
From Step 326 the processing proceeds to Step 328, also shown in
At step 334 a determination is made as to whether the previous channel is available. Of course if this is the first time through, no previous channel will exist. If the previous channel is not available, at Step 336 a determination is made as to whether the next channel is available. If the next channel is available, at Step 338 a determination is made as to whether or not the priority is lower and it is time to switch. The determination is made by looking at the information in the User Configuration 208 (
Returning to Step 334, if it is determined that a previous channel is available, at Step 344 an inquiry is made as to whether or not the previous channel has a higher priority and it is time to switch. The determination is made by consulting the information in the User Configuration 208 (
If at Step 344 it is determined that it is not time to switch and the priority is not higher, processing proceeds to Step 336 where it is determined whether the next channel is available. If the next channel is not available, at Step 348 the current channel is not switched and the processing proceeds to Step 341 as described above. If at Step 336 the next channel is available, then at Step 338 the inquiry into priority and time to switch is made as previously described. At Step 338, if it is not time to switch and the priority of the next channel is not lower, the Router 200 stays on the current channel at Step 348.
Refer now to
If at Step 346 it is determined that the availability of all channels has been checked, at Step 352 the availability of the present channel is determined. If the present channel is available, a connection is made at Step 354. If the present channel is not available, processing proceeds to Step 356 for error handling. The error handling procedure is discussed with reference to
Referring now to
The Router 200 of the present invention may be used inside a mobile vehicle, or carried by a person in a portable application. Further, the Router 200 may be provided as an external component connected to a portable device (e.g., a laptop computer) or may be implemented within the portable device, such that the portable device and the Router 200 are provided as one integrated unit. Further, the Router 200 may be used in conjunction with, or integrated into measuring and testing equipment, and transmission equipment. Such a remote device may be needed for very remote monitoring applications, such as wildlife studies, etc., necessitating the use of multiple Networks.
Referring now to
The Application layer consists of various processes that perform services directly related to the function(s) for which the device is defined. This includes such services as defining a device configuration, making decisions about which route to select for the transport of data and performing various diagnostic functions.
The Presentation layer consists of a protocol-independent insulating layer between the applications and the lower-level networking functions. The Presentation layer implements a Berkley sockets compliant application programming interface (API).
The Networking layer performs all processing related to handling the Internet Protocol (IP). The main function of the networking layer in this environment is the routing of data passed into the layer from either above or below back out through selected Network Interfaces to deliver that data to the intended destination. The relationship of destination and network interface is maintained by the Configuration Module and Routing Decision Module applications.
The Data-Link layer provides logical Network Interfaces through which the Networking Layer may send and receive data. One or more of these Network Interfaces may be active at any time. At least one network interface must be active for the device to function properly. The main purpose of the Data-Link layer is to insulate the Networking layer from the details of the many link-level protocols used to transport data.
The Device-Specific layer deals with the details of establishing and maintaining data communications through various types of communication devices such as radios, modems and data controllers. Each Device-Specific driver handles the vagaries of configuring and interfacing with various types of communication devices while presenting a uniform interface to the Data-Link layer.
The Physical Interface layer handles the direct interface to external components. For example: A serial port driver may handle the sending and receiving of individual data bytes through a specific type of serial controller such as an Intel 8250.
A description of the functionality supported by various module blocks as presented in
The Configuration Module 222 is an Application layer module that allows a technician to maintain a database of device configuration information. A technician may access the Configuration Module via a diagnostic serial port. Another implementation may allow a technician to access the Configuration module through any of the defined Network Interfaces via a standard socket.
The Routing Decision Module 220 selects the preferred network interface through which outbound data is transmitted. This decision is based upon a variety of metrics including: Interface availability; Time of day; Type of service required; Interface priority and others. Examples of various routing metric schemes are presented later.
The TCP/IP Socket Interface 224 supports an Application Programming Interface (API) which, for example, conforms to the standard Berkley sockets paradigm. Its purpose is to shield the Application Layer from the details of the underlying networking protocols. It allows different network implementations to be employed without the applications being required to adapt.
The TCP/IP Router/Gateway 226 implements standard IP host support with the additional capability of being able to act as a gateway between multiple networks. IP datagrams received by this layer that are not destined for a local IP host address are forwarded through the network interface that is currently designated as the preferred route for the given destination address. It is possible that the management and selection of preferred routes is implemented by the Routing Decision Module 220 in the Application layer.
The PPP Protocol Driver 228 provides a network interface whose data-link protocol conforms to the Point-To-Point protocol standard. The SLIP Protocol Driver 230 provides a network interface whose data-link protocol conforms to the Serial-Line Internet Protocol de facto standard. Other protocol drivers 230 may be implemented which provide Network Interfaces which support either existing protocols or future protocols. The intent is to convey that the underlying link-layer protocol is transparent to the upper and lower layers and that additional protocols may be easily supported.
The MDC Interface Driver 234 provides device-specific support for Mobile Data Controller 54, as described above. The CDPD Interface Driver 236 provides device-specific support for a Cellular Digital Packet Data controller. Other device-specific drivers, e.g., Modem “X” Interface Driver 238 may be implemented to support current or future devices.
The Serial Port Driver 240 deals with the hardware aspects of asynchronous serial data communications such as manipulating a Serial I/O controller or other such external interface. Other physical layer drivers 242 may be implemented which support different external interface devices either existing or in the future.
Although the invention has been described herein with reference to particular means, materials and embodiments, the invention is not intended to be limited to the particulars disclosed herein; rather, the invention extends to all functionally equivalent structures, methods and uses, such as are within the scope of the appended claims.
For example, the router of the present invention may be included as an internal component of the mobile device, proving for an integrated mobile device. Optionally, the router may be implemented entirely as a software process running on, for example, a portable personal computer. In such an implemention, the internal slot(s) of the personal computer may be provided with network interface(s) and a software program may serve as the router core. Further, data may be routed to the different networks at another level than at the packet level. For example, entire messages may be routed over various networks if such a configuration is required.
Claims
1. A method of end-to end data communications where data is transported via incompatible transmission formats in a transparent manner between a remote device and a host communication network using a wireless communications link, said remote device and said wireless communications link being connected to a mobile data controller, said host communication network and said wireless communications link being interfaced by a network interface device logically residing on said host communication network as a protocol-appropriate communications controller, said method comprising the steps of:
- converting data to be transported between said remote device and said host communication network, said converting step converting said transported data between a remote device transmission format utilized by said remote device and one of a plurality of digital and analog wireless link transmission formats utilized by said wireless communications link;
- transporting said transported data over said wireless communications link in accordance with said one of said wireless link transmission formats;
- receiving said transport data from said wireless communications link;
- converting said transported data between said one of said wireless link transmission formats and a network interface format utilized by said network interface device, said one of said wireless link transmission formats and said host network format being incompatible;
- further converting said transported data between said network interface format and a host network format utilized by said host communication network; and
- forwarding said transported data to said host communication network in accordance with said host network format.
Type: Application
Filed: Jun 30, 2005
Publication Date: Aug 24, 2006
Applicant: PADCOM, Inc. (Bethlehem, PA)
Inventors: William Doviak (Pottstown, PA), David Whitmore (Bethlehem, PA), Flex Houvig (Wayne, PA)
Application Number: 11/170,077
International Classification: H04Q 7/24 (20060101); H04J 3/16 (20060101); H04Q 7/00 (20060101); H04J 3/22 (20060101);
