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?