 |
www.conserver.com |
|
|
www.conserver.com |
|
Support for a mobile site |
|
Case Overview Original Project Page |
This page covers a hypothetical case, based on a real testbed. That is, I was on a team, tasked with designing a rolling demo truck/trailer, which would need to provide 'dialup' connectivity to a home network, for telco-interfaced products (without needing the truck to back over a telephone booth to get dialtone).
The testbed was designed, and tested, inside of two weeks. During that time, we also brainstormed how this remote site might need to be supported, and possibly remotely managed using the satellite network connectivity. The images on this page were created for the original project in 2001.
As a concept, the truck would have GPS on-board, to assist the the driver with navigation. While parked, the trailer would use a small-aperture satellite dish, which would automatically acquire it's sattelite. The GPS would help it get a start, but the dish (with it's controlling computer) should be able to find the correct satellite without the GPS. Once the satellite was acquired, the modem in the truck should be able to synch with the modem at the main data center, establish a high-speed data link to the trailer, and connect with the dial-up Point-of-Presence gear on the trailer. The demo consisted of a dialup device in the trailer 'calling' into the P.O.P. gear in the trailer, which would then use the satellite link to pass the network traffic as needed.
|
Physical Communications Overview The 'Network' at the top was within the firewall of an ISP, rather than using a VPN from a commercial satellite uplink/downlink providers network. The link speed was basically T-1 (1.544 Mbps), and we would not see significant traffic on the ethernet interfaces on the routers on each end of the link, so we pressed a pair of Cisco 2500 routers into service for the link. The tesbed used RF up-converters between two satellite interfaces. These were essentially QPSK modems, and were interfaced to the network routers as though they were a T-1 CSU/DUS-type interface. (In the real world, the upconverters would be replaced by a pair of satellite uplink transmitters and downlink receivers.) Because the devices being demonstrated in the field had standard POTS (Plain Old Telephone Service) interfaces, we needed to put a phone system and dialup Point of Presence in the remote truck. This was accomplished using a Gordon Kapes System 930 telephone system simulator, and an Ascend Pipeline NAS 2 (later acquired by Lucent Technologies), because these were pieces that we had readily at hand. The Ascend NAS was used in an earlier version of the ISP dialup network, so the network was ready to treat the NAS as though it were an older Point Of Presence. The 'network-side' router was connected to the ISP network subnet where the other dialup connections came together. The Gordon Kapes device could be provisioned to require 'dial 9' access, or need '1+' long-distance dialing, so we could provison the test trunks for various situations, as might be required of the demonstration. (This was a way of future-proofing the telco-side needs in the truck.) The dialtone of the Gordon Kapes was contained withing the confines of the truck, so the demo truck 'staff' could not use it for personal calls. This would be handled using cell-phones or land-lines. (The datalink would, however, provide the truck with email capability.) |
 |
With the network connectivity established, there were issues 'above the application layer' that needed to be addressed. We didn't think that the truck driver would be a network or systems administrator, so we needed to provide on-truck diagnostics and documentation, as well as considering how the Networks Operations Center (NOC) staff might be able to manage and support the equipment in the truck, once the satellite link was established.
|
Mobile Site Network Management Overview This image showed the 'Logical View' ow what the NOC might be called upon to manage the equipment in the remote truck. This is only the equipment on the 'far side' of the satellite link, since the 'near side' components would always be attached to the network, and manageable with the normal means (SNMP, Conserver, Cricket, and specialty tools.) This all depended on the satellite link coming up normally, providing a working data path between the remote site and the regular network... It was determined that we should have an on-board PC, with the 'local documentation' as HTML docs on the hard disk, and to host the email program, and any diagnostic tools for the satellite gear. (The platform choice was initially chosen due to the relationship of the ISP network to a large company that provides operating systems for Intel platforms.) As a secondary consideration, we discussed having a Diagnostic P.C. as well, likely running some flavor of Linux, to provide a local web server (as a test target for the dial-up set-top boxes, in case the satellite link could not be established), and also running tools, such as Conserver and PERL, to help monitor and log the on-truck equipment (even if the link was not running). The installation would include upgrading the remote router from the Cisco 2500 series to a Cisco 3620 (or similar, having one ethernet, and a 16-port async interface, to provide console connections). There was an option to use a 'debug' dial-up device, which would also allow us to capture errors from the dial-up Set Top Box (STB), in case there was a need to find out what the STB was thinking... |
 |
Using Conserver in "distributed mode" meant that the Diag PC could perform the local logging for all on-board serial ports that would be monitored, allowing us to have some forensics to see what the devices might have been complaining about while the satellite link was down. Plus, when the link was established, the NOC would have been notified (via SNMP) that the remote truck was on-line, and then the NOC could use their local conserver to access the consoles on the truck, should the need arise.
By splitting the serial line from the on-truck GPS unit, the router, or the diag PC could use this satellite-based time reference to provide a high-stratum NTP time source for the equipment on the truck, to improve the accuracy of timestamps used in the logging on Conserver. This would make it easier to coorelate timestamps from logs on-board the truck with logs in the data center, in cases where file access audits were needed (perhaps to find out why a particular URL was denied, or a STB command was refused).
For troubleshooting the satellite link, we might need to wait for the link to be established, but we could then find out what problem(s) had been the cause of the trouble, by combing through the logs for the satellite modem, the router, and the satellite control PC.
The image below shows the testbed on my desk. The routers and the satellite modems are on the left side of the PC, and the Gordon Kapes phone simulator is holding up the Ascend NAS on the right side of the PC.
|
NOTICE: Most of the pages, articles, and tutorials on this website are copyrighted works. You may make 'deep links' to various pages. (If you let me know which page(s) you are linking to, I'll let you know if I move the page(s) during updates.) Please send me email if you wish to republish any material, or use it on your own website. |
