IEEE P1451.5 Wireless Sensor Interface Working Group
Comments on use of Bluetooth Technology
Peter Flittner
Cambridge Silicon Radio
Science Park,Milton Road
Cambridge, CB4 0WH, United Kingdom
Tel: +44 1223 692000
www.csr.com
www.btdesigner.com
IEEE 1451 Smart Transducer Interface
XDCR
ADC
Transducer Independent
Interface (TII)
ACTR
DAC
Address Logic
XDCR
Network Capable
Application Processor
(NCAP)
DIO
Transducer Electronic
Data Sheet (TEDS)
Bluetooth could replace either
TII or network connection
Smart Transducer Interface Module (STIM)
Network
Extending IEEE1451 to Wireless Technology
•
Adding wireless technology to industrial sensor networks has to solve two main
problems:
– Devices are not always connected
– Devices may be battery powered and therefore not always connectable
•
Question: Can IEEE1451.5 add generic extensions to the information model that
allow multiple wireless solutions to be used interchangeably?
Possible solution:
– Define a common Quality of Service (QoS) requirement for transducer
communication that can be mapped to any radio technology
– Each radio technology has a mapping layer that maps radio-specific
configuration parameters to QoS requirements
•
IEEE1451.1 Network communication models
•
•
•
•
•
The IEEE 1451.1 standard provides two models of network communication between
objects in an system
– A tightly coupled, point-to-point client-server model for one-to-one
communications
– A loosely coupled, publish-subscribe model, for one-to-many and many-to-many
communications
The communication models define the syntax and the semantics of the software
interfaces between application objects and a communications network.
These interfaces are independent of the specific network being used.
Question: Can IEEE1451.5 use the same communication models?
Possible solution:
– Mains powered devices can use client-server model, possibly transparently to
existing IEEE1451 systems (enables legacy markets)
– Battery powered devices can use publish-subscribe model, to send sensor
readings to meet QoS requirement
IEEE1451.5 NCAPs
•
The NCAP can be implemented in several different ways using wireless technology:
– A minimal NCAP that can be implemented on a radio module connected to a
single STIM using a wired connection
– A minimal NCAP that can be implemented on a radio module connected to a
small number of STIMs wirelessly
– An NCAP with significant processing capability that connects many wireless
STIMs to the network (NCAP acts as access point)
– An NCAP with significant processing capability that uses dumb access points to
connect to the network
Bluetooth IEEE1451.5 Models - Bluetooth NCAP
Bluetooth Module
Wired TII
STIM
•
•
•
•
NCAP
Bluetooth/wired
connection to network
NCAP implemented on Bluetooth module with wired TII
Allows legacy STIMs to be made wireless
Typically add $10-50 to cost of STIM
Existing Bluetooth chips could implement TII (possibly with some additional logic/
ICs)
Bluetooth IEEE1451.5 Models – Bluetooth TII
Bluetooth module
Bluetooth TII
STIM
•
•
•
•
•
NCAP
Bluetooth/wired
connection to network
Logical TII defined as profile over Bluetooth transport layer
Logical TII can be independent of wireless technology
Point to point connection can be made to single STIM with no extensions to
Bluetooth profiles
Multipoint connection to many STIMs requires connection/power management
Existing Bluetooth chips could implement logical TII
Bluetooth IEEE1451.5 Models- Integrated TII
Bluetooth module
Integrated TII
STIM
•
•
NCAP
Bluetooth/wired
connection to network
For lowest cost wireless transducer can be integrated chip level so TII is an ASIC
interface
Future Bluetooth chips could implement integrated TII for high volume transducers
Questions
•
•
•
•
•
•
•
Can an NCAP be implemented on a Bluetooth module?
Should Bluetooth be used on network interface or TII, or both?
Should an IEEE 1451.5 proposal adopt Master/Slave roles?
Should an IEEE 1451.5 proposal assume dumb wireless Access Points (AP) on
existing wired networks, or should knowledge of the wireless technology be
assumed?
Should an IEEE 1451.5 proposal define a QoS request to be interpreted by access
point or NCAP?
Should a Connection Management packet specify Bluetooth power/connection modes
for TII or network connections?
How could Bluetooth transducers deal with synchronised time?