doc.: IEEE 802.15-0931-00

Submission

November 2007

Daniel Lewis, NICTASlide 1

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Submission Title: Some lead BAN user requirements and constraints: A summary and analysis of interviews with some lead users BAN usersDate Submitted: [13 November 2007]Source: Daniel Lewis Company NICTAAddress Locked Bag 8001, Canberra ACT 2612, AustraliaVoice:+61 (0)2 61256112, FAX: +61 (0)2 6230 6120, E-Mail :daniel (dot) lewis (at) nicta.com.au ]

Re: [Response to Call for Use Cases and Applications]

Abstract: [A summary and analysis of interviews with some lead BAN users]

Purpose: [To promote discussion within the BAN group of the user requirements and constraints of some lead users]

Notice: This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15.

doc.: IEEE 802.15-0931-00

Submission

November 2007

Daniel Lewis, NICTASlide 2

Some lead BAN user requirements and constraints

A summary and analysis of interviews with some lead BAN users

Daniel Lewis (NICTA)

doc.: IEEE 802.15-0931-00

Submission

November 2007

Daniel Lewis, NICTASlide 3

Overview

• Lead User Interviews

• Lead User Use Cases– Elite Sport (Individual and Team Sport)

– Emergency Services (Fire Fighters)

– Medical Devices (Implants)

– Defence (Fatigue Management and Monitoring)

• Common Requirements– Point-to-Point Link Needs Analysis

– Data Types Needs Analysis

• Conclusions

doc.: IEEE 802.15-0931-00

Submission

November 2007

Daniel Lewis, NICTASlide 4

Lead User Interviews

• Elite Sport– Monthly interviews with Peak Elite Sport Body over 12+

months (ongoing)

• Emergency Services– 2-3 interviews with State Fire Department (ongoing)

• Medical Devices– 2-3 interviews with State Health Department (ongoing)– Interviews with implanted medical device company

(ongoing)

• Defence– 2-3 interviews with Soldier Health & Safety Management

Area and others (ongoing)

doc.: IEEE 802.15-0931-00

Submission

November 2007

Daniel Lewis, NICTASlide 5

Elite Sport Requirements and Challenges

• Wearable device which detects body movement characteristics for individuals

– All activities• Gate length, acceleration,

positioning, heart rate, O2, etc– Swimming

• Lap split times, acceleration, position, hear rate

– Cycling• Motion analysis, etc

• Team Sport– Team interaction, field ‘scrums’,

plus individual data• Aprox data rates 30kbps

• Wearing devices must not impede athletic performance

• Swimming needs custom ‘off body backhaul’ which works underwater

• In team sports, highest data rates occur when players are bunched together;

– the time of maximum interference, shadowing and reflections

• Coach needs to be able to examine data in real time and analyse offline

doc.: IEEE 802.15-0931-00

Submission

November 2007

Daniel Lewis, NICTASlide 6

Emergency Services (Fire Department) Requirements and Challenges

• At a fire, one engine acts as a situation command, and needs to know– Is my fire-fighter inside

building alive? (heart rate, breathing rate)

– Position information (where are they in building)

– Be able to give instructions to the fire-fighter (voice)

• Fire-fighters are typically already ‘connected’, with existing data backhaul

• Devices need to be rugged and not interfere with the performance of tasks

• Data Characteristics– Occasional bursty large

data (maps etc)– Guaranteed low rate back to

the truck eg, emergency ‘help button’

doc.: IEEE 802.15-0931-00

Submission

November 2007

Daniel Lewis, NICTASlide 7

Medical Implants Requirements and Challenges

• Devices need to be able to communicate between each other within the body (10-20 kbps)

• Devices need be able to communicate with the outside

• Very low power• Long battery life needed• Devices negotiate how to

behave when power is failing (no silent failure)

• Radio is provably secure

• Devices need to be wirelessly ‘flash upgradeable’, high data rates for short periods– Eg, upgrading the firmware

on hearing aid implant, pacemaker etc

– Eg, diagnostic data, during installation process

doc.: IEEE 802.15-0931-00

Submission

November 2007

Daniel Lewis, NICTASlide 8

Defence Requirements and Challenges

• Commander needs to know– What is solider X doing now?

• Running, digging, etc– In what condition are they

• Healthy (Green)• Injured (Orange)• Critical (Red)

– How fatigued is soldier X, are they able to perform task Y?

• Individual solider and aggregate views (eg unit level)

• Soldiers are typically already ‘connected’, with secure existing backhaul

• Devices need to be rugged and not interfere with the performance of tasks

• Secure– Can’t be used to identify their

location for ambush (low power to avoid RF detection)

– If they loose it, it can’t be used by the enemy for intelligence

• Non-transferable– You can’t use it to pretend the

wearer is still alive

doc.: IEEE 802.15-0931-00

Submission

November 2007

Daniel Lewis, NICTASlide 9

Point-to-point Link Needs AnalysisLink Needed?

Internal-internal

Internal-Surface

Surface-Surface

Surface – External

Sports No No Yes (no existing solution)

Yes (limited existing solutions)

Defence No No Yes (no existing solution)

Yes (but have existing secure solutions)

Emergency Services

No No Yes (no existing solution)

Yes (but have existing secure solutions)

Medical Implants

Yes (no existing)

Yes (no existing)

Yes? (no existing solution)

Yes (no existing solutions)

BAN Focus area?

doc.: IEEE 802.15-0931-00

Submission

November 2007

Daniel Lewis, NICTASlide 10

Data Types Needs Analysis

• Three ‘in-common’ types of data traffic– High bandwidth, short bursts

• Eg, software upgrade, ‘data dump’, map transfer

– Continuous, ‘best effort’ delivery• Eg, Pulse rate, breathing rate, body position

– ‘Get this message our at all costs’• Heart has stopped, breathing has stopped, heart-attack in

progress– Doesn’t matter if the device is destroyed in the process (eg

use all available power, violate recommended SAR emission levels if needed)

doc.: IEEE 802.15-0931-00

Submission

November 2007

Daniel Lewis, NICTASlide 11

Conclusions

• Extensive detailed interviews with four lead user groups– Enthusiastic responses to discuss BAN– BAN addresses pressing real user needs

• Some data links are more important in others depending on use case (eg, internal-internal, internal to external)

• Three Basic Data Types (bulk data, low rate, ‘emergency send’