On Saturday, July 27, 2002, at 02:32 , Ken Chang wrote:
> what bandwidth do you think is required for video?
short answer: something in the 1Mbit/s range
THEREFORE maximum range 1 meter
AND absolutely lowest priority ever
> I see two issues for a mass market radio interface important:
> - capacity/interference, and
for starters capacity is no issue whatsoever
> - security
Something like OpenSSH will do just fine, no issue at all
> for Bluetooth, the capacity for audio appliances in public may
> be enough for now, but I doubt there is room left if you want
> to use Bluetooth in a wide range of digital devices (it won't
> useful if not).
for smart remote control, bandwidth is not an issue at all
anything will do -- even 300 bit/sec will be just fine
plenty of devices at long range (10m) will be no problem
Let's assume you have the following equipment
- desktop computer
- rice cooker
- microwave oven
- coffee maker
- air conditioner
- air fan
- living room lights
- TV set
- stereo
- VCR
- mobile phone
- cordless telephone base
and assuming a big house, you may in addition have
- BT repeater for living room
- BT repeater for kitchen
now that's a total of 14 devices
how much bandwidth do you need to switch channels on the TV ? How much
to mute the TV and stereo when either the mobile or the cordless phone
is being picked up ? How much to program your rice cooker, your coffee
maker, your microwave, your VCR ?
Let's assume we won't even code the commands but instead send them in
plain English such as ...
Scenario: Phone is being picked up for incoming or outgoing call
- Attention TV set // mute sound to 10% now // end
- Attention Cordless Base // sound muted // end
Scenario: Incoming message from mobile via internet "Master is coming
home late @2100hrs"
- Attention VCR // request schedule recording channel 28 @1900hrs today
duration 90mins // end
- Attention Desktop // acknowledged recording channel 28 @1900hrs
today // end
- Attention Microwave // request cooking time for next job today // end
- Attention Desktop // answer cooking time is 8 minutes @1852hrs
today // end
- Attention Microwave // reschedule next job for 2052hrs today // end
- Attention Desktop // acknowledged next job now 2052hrs today // end
- Attention Rice cooker // request cooking time for next job today // end
etc etc etc
Note that jobs which need to be completed in real-time can be done with
very short commands, such as switching a channel on TV, muting the
sound, switch a/c on or off etc, while jobs which require longer command
sequences do not require real-time, such as is the case with programming
a device, which may be allowed to take a few seconds.
Thus, even with a very chatty protocol such as in the above examples,
you can easily go along with very low bandwidth. 300 bit/sec will do
just fine.
but even assuming 600 bit/sec and 14 time slots, we're at 8400 bit/sec
plus a bit of overhead, all in all we'll hardly go over 9600 bps.
> security is a terrible problem.
not with SSH
> is Bluetooth really secure so that we don't have to worry?
> http://www.niksula.cs.hut.fi/~jiitv/bluesec.html
what does it matter whether it's BT or IP or USB or FW ?
as long as you are able to send data over a link, you will be able to
send digital certificates, signatures, challenges, public keys etc etc
etc and then encrypt the session with a session key never to be reused
again.
If I want to use my mobile to switch channels on my TV, then I have to
register the mobile with the TV once or else the TV won't allow the
mobile to control it. So where is the problem ?
> the IS-41 AC is way better than GSM AuC
because IS-41 uses a public algorithm and GSM uses a secret one. Yet by
now every child knows that security by obscurity doesn't work. So, if
you want your BT application to be secure, don't invent yet another
"security by obscurity" scheme but use a public algorithm such as PKE
and digital certificates to secure your session.
regards
benjamin
Received on Fri Jul 26 22:17:45 2002