The definition of IBOD here is rather different. It is here intended as a mechanism for delivering internet-derived content/data to any location on Earth without a fixed connection, without an ISP contract, and without direct satellite use. IBOD is designed to send URL requests and other upload responses via any radio frequencies (but may use other means-see below). These signals are received by RF/Net repeating stations that pull the data requested from the internet, and transmit it back on a stipulated frequency to the original requesting source.
Computer/RF interaction is not new. Nederlanse Omroep Stichting and BBC Radio 4 were broadcasting programs to 8-bit computers twenty years ago. Today radio data modems use TCP/IP (usually on VHF frequencies) for data transmissions. There are numerous specialised data transmission protocols. Adrian Robinson (G7WFM) pioneered the use of hybrid (internet/RF) repeater stations in the UK on the 70cm band. Icom are working with the D-STAR concept on VHF and UHF. None of these technologies are intended to be particularly cheap, long-distance, or non-proprietary. Generic and widespread IBOD deployment would allow much longer distances of communication and coverage of highly remote areas, the IBOD protocol would be published, all software could be Open Source, and no ISP contract would be required. The primary products supported by the technology for sale may be RF/Net repeater installations, a supported/boxed edition of software, and the increased sale of dedicated/optimised TX, RX, and TRX units.
IBOD is intended to offer a free-to-dirt-cheap operational internet access protocol for remote and developing-world locations. No ISP is required and a PC's sound card is used as a virtual modem. Using altered dial-up software, digital URL requests would be converted to analogue audio and switched to the line-out of a PC's sound card into a radio transmitter. Data received would come from a radio receiver, in through the sound card's line-in socket, be converted to digital data, and passed to a browser or e-mail program.
The service can operate with a public service (governmental/UN) infrastructure of RF/Net repeaters operating automatically under solar/storage cell power, private RF/Net repeating services operated by NGOs or hobbyists, or both. Data may be encrypted (e-mail, SSL sites) or unencrypted (ordinary web pages) in either direction. PC-based encryption ensures no special secure (and expensive) RF protocols need be used. Receiving software could default to block anything potentially malicious (scripts etc). Spare space within the TRX protocol layers or packets would identify the user, GPS locations/Map references if available, response frequencies, repetition rates, and nominated repeaters.
A repetition rate flag would request that data be sent a set number of times, if reception was poor. If multiple responses overlapped and caused problems, specific repeaters could be ask to 'not answer' specific requests. Excessive usage/abuse would lead to automatic rationing/cessation of a service to specific users. Repeaters could reply with a directional signal, with vertical or horizontal polarisation, and with specific power levels to suit individual requests. RF/Net repeaters would normally have satellite or fixed link internet access to send on and receive packets for users, but may (in difficult environments) operate as a node on a repeater-based WAN using a higher frequency for repeater-repeater networking, bouncing signals across a grid of other repeater stations according to ad-hoc availability, before connecting to the internet.
Note that a request could be made to a specific repeater, or to any repeater hearing a signal. During periods of unusual atmospheric behaviour, it may be that a user can only send a request and receive a response from a repeater on a different continent. Protocol data space would allow for the automatic logging of such issues, and a central web site could aggregate local data path information for RF/Net repeater operators. This would allow the automatic, incidental mapping of global tropospheric interference.
A global standard for IBOD would assist in its development. Specific licenses to transmit IBOD data on set frequencies may be required in some countries, although in many, any licensed operator could send IBOD requests or operate a repeater. Such licensed users are common in remote areas.
The service is not primarily intended for heavy users, streaming media, or commercial usage, but to connect remote and developing communities. Low cost standardised and optimised modules could permit economic and robust reception of unrequested IBOD data (ie. timed/open transmissions and 'push' services). This may be a primary usage of the service, with one-to-many broadcasts of educational, meteorological, and informational material in HTML format on various radio frequencies to entire continents. IBOD requests could also be made by post and phone. When not transmitting data, and as a regular feature, an RF/Net repeater should identify itself using speech and a data protocol, to allow users/software to know which repeaters they could receive, and how they may send requests to them via various means.
A timed/dated transmission of specific data may even be booked in advance for research expeditions, weather and news data.
TCP/IP may be unsuitable as a transmission protocol for IBOD. IBOD operates somewhere between half-duplex and full-duplex with the software hoping for one or more responses to a URL request, but not immediately, and with no operational reliance upon immediate dynamic handshaking. A customised protocol that maximises and standardises data transmission (packet length etc), permitting encryption, but losing irrelevant layers would be appropriate. The RF/Net repeater would translate packets between protocols and act as a data cache (as internet-based data may change before a full transmit has been completed). IBOD also requires a high distinction protocol, where a data one, a data zero, no data, and no signal/static are designed to be as dissimilar as they can be.
A previous design for a one-way transmit-to-net protocol for an embedded device would be relevant for IBOD communications. This was originally designed to allow devices to be attached to the net but unaddressable, to protect them from DDoS attacks.
Back to Stig's Dump.