The Retrospective Token Bus Protocol forms an Intellectual Property Product . The protocol operates on the basis of retrospectively passing a logical token over a bus topology network . The protocol is highly efficient and highly reliable - has the efficiency of a token ring network with the reliability of a bus network . It is simple and cheap to implement . Patents have been applied for and have been granted .

As the company is essentially an Intellectual Property based company it is interrested in joint arrangements where financing is supplied from external sources . We can not only supply the Intelectual Property but also extensive expertise - both technically and with regards the business side .  

The Retrospective Token Bus Protocol can be used for all types of networks from office and telephone networks to industrial and home networks . It is ideally suited for use in Domestic Area Networks because of it's following advantages :-

1. low cost implementation - thus providing for a commercially attractive addition to domestic devices .
2. small IC real estate - thus allowing incorporation onto single chip solutions .
3. bus topology - low cost physical medium - can use existing cabling . Also highly reliable .
4. highly efficient - the low data link overhead means that the usage of the data link speed is maximised .
5. reliability and predictability of the time usage of the communication cycle - no drop outs due to packet collisions - ensures that intensive use such as pumping Digital Video around the home is conducted reliably - without drops outs and within the time requirements .

The Retrospective Token Bus Protocol is ideally suited to Quality Of Service issues :-

1. it has the features and it can be vaired such that all QOS issues can be handled fully .
2. it is ideally suited as the LAN end of an ATM style network . It can also be used as a general LAN protocol .

Please Note :- the information supplied here is only what is in the public domain . Commercially confidential information is not shown . This includes varations on the protocol that have not yet been patented .

The Retrospective Token Bus Protocol versus the Ethernet Protocol

The Ethernet Protocol in a multidropped \ bussed topology ( eg. 10Base2 ) has a large and unpredictable data link overhead due to it's Carrier Sense Multiple Access \ Collision Detection access method . In large networks this can be easily 25% to 50% . The more units that are trying to transfer data at the same time the more the Ethernet crashes - the more drop outs and retries - hence the massive increase in data link overhead . There is also massive data link overhead with units waiting for the network to become available - inactive wait times . The Retrospective Token Bus Protocol , however , has a very low data link overhead of , typically , 0.25% to 0.5% and this overhead is very predictable . As such the Retrospective Token Bus Protocol is very suited to high network usage applications such as multi media networks such as domestic networks .

The Ethernet Protocol in a star topology ( eg. 10BaseT - ie. requires a hub ) using packet switching does not have the data link overhead of the bussed topology . However the cost of the network is considerably greater than a bus topology based network . The Retrospective Token Bus Protocol , however , has low overhead and low cost .

The Retrospective Token Bus Protocol versus the Token Ring Protocol

The Token Ring network has high unreliability . If , for example , the network has 100 units and each unit's network interface has a reliability of 100,000 hours ( 12 years ) then the reliability of the network is 100,000 / 100 hours -> 1000 hours ( 6 weeks ) . This inherrent problem has to be designed around . Secondly the Token Ring network requires more wires - usually 6 - as opposed to 2 for a bussed topology . The Retrospective Token Bus Protocol , however , has the very high reliability and low cost of a bus network .

The Retrospective Token Bus Protocol versus IEEE802.4

IEEE802.4 is prospective token passing protocol . As such the token is passed explicitly from the current unit to the next logical unit . This results in a complicated and costly design . The Retrospective Token Bus Protocol , however , passes the token retrospectively - the next logical unit takes up the token rather than being explicitly passed the token . As such the Retrospective Token Bus Protocol is very easy and cheap to implement . Further because it requires very small chip space it is suited to low cost integrated applications such as would be found in domestic networks .

The Retrospective Token Bus Protocol versus Wireless LAN's

Wireless LAN's use CSMA\CD type access protocols and are similar in that respect to Ethernet . They have , as such , a high data link overhead . Their bandwidth is , also , low . Where a cable system can easily operate at 100 Mbs a wireless LAN will typically operate at only 1.6 Mbs - far too low for multimedia applications . Further , wireless LAN's have space and hence bandwidth contention problems in densely populated areas such as in cities . All these problems produce both a reliability problem and a performance problem for multimedia - ie. there is no guarantee that the multimedia packets will get through within sufficient time . Further there is the cost factor - a Retrospective Token Bus connection will cost typically U.S. €2.50 per unit whereas a Proxim LAN , for example , will cost approximately U.S. €129 .

The Retrospective Token Bus Protocol versus Bluetooth

Bluetooth has all the disadvantages of a wireless LAN . It is designed primarily as a point to point technology . It is designed as a connection point to a LAN . It is limited in distance and in speed . It is costly . It is good as an entry point to the Retrospective Token Bus network but Bluetooth is not suited as a LAN on itself .

The Token Bus Network

The Token Bus Network can operate on a twisted pair cable at 100 Mbs or faster . Alternatively thin coaxial cable can be used . As such existing telephone cableing or low cost prefabricated cabling can be used . It would be possible to put in an autobauding and speed negotiation system if required , however , this shouldn't be required . There is no reason why , taking into account the practicalities , that the whole design of the physical side of the network can't be minimised cost wise . This includes , for example , using an RCA plug and socket instead of a BNC . Whilst it is common for LAN cards to use isolation transformers cheaper alternatives can be looked at .

Development

I would recommend that a version of Token Bus Protocol 2 be used with some Token Bus Protocol 3A techniques . This would use the active and passive token passing , arbitrary unit number assignment , network based addressing and broadcast channel addressing . It would essentially operate as a MAC style protocol - not requiring any MAC level intelligence . This would minimise the design complexity and the IC real estate required . Care would also have to be taken to ensure that the Data Link Level - Media Access Control - works in all the practical situations - both protocol and physical wise .

First Stage

Company Setup

Development of Xylinx based prototyping cards .
Development of logic design .
Commencement of writing of packet driver .

Allow 3 months .

Staff required - 1 Hardware Engineer ( contractor ) + Myself .

Equipment Required - 4 PC computers + design software for the Xylinx + tools + hardware .

Estimated cost U.S. € 150,000

Second Stage

Development of ASIC based design .
Prototyping of ASIC .
Writing of packet driver .

Allow 3 months .

Estimated cost U.S. € 200,000

Third Stage

Development of Network PC and Gateway boards .
Completion of writing of packet driver .
Testing .

Allow 3 months .

Estimated cost U.S. € 150,000

Initial Investment

Set initial investment at U.S. € 500,000

At this point we will have a fully up and running Retrospective Token Bus based Domestic Area Network implementation . This will allow us to make decisions as regards final forms - eg. integrated with a processor and with on chip RAM . We can also decide product forms - eg. chips placed in equipment , PCMCIA cards , PC cards etc. .

For more details please contact me .

Internet Appliances

Networked Internet T.V.

A Networked Internet T.V. would allow the video source to be obtained from any unit on the network - rather than just a single source such as a Digital T.V. Set Top Box . As such it would greatly increase the versatility of the T.V. . All that would be required is a board with a full featured browser and the Domestic Area Network Connection . It would be important that the software on the board be modularised and componentised such that the individual component elements can be loaded from a remote site when updates are required . This would mean that updates can occur with much smaller local memory requirements and at a much faster speed .

Networked Loud Speakers

A Networked Loud Speaker would allow the audio source to be obtained from any unit on the network - rather than just a single source such as a T.V. or a Hi Fi .

Networked Hard Disk Drive

A Networked Hard Disk Drive would allow the user to store files remotely - such as files from a Palm Top . It would also allow these files to be exchanged between computers . Networked Hard Disk Drives allow storage capacity to be easily and cheaply increased . The addition of a SMTP and POP3 server allong with remote HTML based access allows the user to manage email remotely . This allows functions such as email redirection and remote access to be carried out .

Networked Cameras

A Networked Camera allows a site - such as a home or a business - to be viewed remotely . This is a facility currently available . The upgrading of the facility to a Domestic Area Network Connection would further improve it .

Networked Security System

A Networked Security System would allow the user , for example , to remotely monitor and configure the alarm system . As such entry id.'s and access numbers could be remotely specified . The user could be notified by email of any entry or entry attempt .

Hotel Network System

The Retrospective Token Bus Protocol allows Digital T.V. , Digital Audio and Video on Demand to be piped throughout the hotel . Further it allows the connection of telephones , computers and facsimile machines to be connected . Digital T.V. can be connected in using IGMP but for purposes of speed and easier handling a direct connection of data streams would be preferable . Similarly Video on Demand - video juke boxes ( DVD stacks ) .

Digital T.V. and Video on Demand would be piped with all programs , all languages and all subtitles . Connection to the individual programs ( T.V. and Radio ) , languages and subtitles would be via data stream broadcast address selection .

Video on Demand would be distributed from DVD stacks . Interfaces would be provided for video selection and for setting up the stacks . These can be initially via the front end module . If the system is ultimately set up such that it can operate on the World Wide Web these can be changed to HTML .

A unit would be provided that outputs the T.V. signal , has optional seperate stereo ( or DTS 5.1 ) audio ( optional - would not be initally required ) , has a telephone connection ( optional - would not be initally required ) and has infra red and optional wireless network connections . Selection of programs would be via remote control . Display would be via an HTML interface .

There would also be a need for gaming servers .

There would also be the need for gateways ( routers ) to link up the individual floor areas .

A speed of at least 100 Mbs would be needed . It will require re-cabling but this is easily accomplished due to the bussed nature of the network topology .

Further there would be business in tying up the hotel into local area web based information and booking sites .