Push-to-Talk over Bluetooth Author: Valter Rnnholm Supervisor: - - PowerPoint PPT Presentation

Push-to-Talk over Bluetooth

Author: Valter Rönnholm Supervisor:

• Prof. Sven-Gustav Häggman

Instructor: M.Sc. Matias Järnefelt

Overview of Presentation

• 1. PoC (Push-to-Talk over Cellular)
• General overview
• Different standards
• 2. OMA PoC
• Architecture
• Services
• Protocols
• QoE (Quality of Experience) requirements
• 3. Research Problem
• 4. Motivation
• 5. Platform: Bluetooth PAN (Personal Area Networking) profile
• 6. Proposal for PoB (Push-to-Talk over Bluetooth)

Push-to-Talk over Cellular (PoC)

• PoC is a simplex one-to-one or one-to-many service
• User experience similar to walkie-talkie
• No dialling needed
• Various different standards:
• Various proprietary standards (e.g. Qualcomm, Motorola, Togabi…)
• Industry standard specified by Ericsson, Motorola, Nokia and Siemens
• Open Mobile Alliance

Figure source: ”Push to Talk over Cellular Real-time always-on voice service”, Espoo, 2003, Nokia Networks Ltd., 12p. www.nokia.com/poc/PoC WP A4.pdf

OMA PoC: Architecture

Figure source: OMA Push to talk over Cellular (PoC) – Architecture, Draft Version 1.0 – 7 April 2004, OMA-AD PoC-V1 0-20040325-D, 102p.

• Standardization in progress
• Baseline: Ericsson, Motorola,

Nokia, Siemens standard

• Target to publish a service

candidate enabler by end of –04 (not available yet)

• Based on SIP signalling over IMS
• PoC Servers handle floor control

and speech traffic

• Group and List Management

Servers handle group management

OMA PoC: Features

• Different types of PoC groups:
• Pre-arranged
• Chat
• Ad-hoc
• An example of one-to-one ad-

hoc group session formation is presented in the figure

Figure source: OMA Push to talk over Cellular (PoC) – Architecture, Draft Version 1.0 – 7 April 2004, OMA-AD PoC-V1 0-20040325-D, 102p.

OMA PoC: Protocols

• Complete control plane and user plane specifications are currently not

publicly available.

• The general protocol stack of PoC is:
• Codec: AMR

Figure source: ”Push to Talk over Cellular Real-time always-on voice service”, Espoo, 2003, Nokia Networks Ltd., 12p. www.nokia.com/poc/PoC WP A4.pdf

OMA PoC: QoE requirements

The OMA PoC specifications set the following QoE requirements:

• 1. Right-to-Speak Response Time
• The right-to-speak response time when establishing a PoC session:

max 2.0 s

• 2. Start-to-Speak Response Time
• The start-to-speak response time in an active PoC session:

max 1.6 s

• 3. End-to-End Channel Delay
• max 1.6 s
• 4. Mean Opinion Score
• The perceived voice quality:

min 3 (at BER < 2 %)

• 5. Turnaround time
• The time from the instant a user releases the floor after he/she has stopped

speaking until the instant the same user hears the beginning of a reply from another user (user behaviour dependent): max 4 s

Research Problem

• “How can mobile phone users be provided with a free-
• f-charge PTT-feature with PoC-like user experience by

means of Bluetooth technology?”

Bluetooth

Figure source: ”Push to Talk over Cellular Real-time always-on voice service”, Espoo, 2003, Nokia Networks Ltd., 12p. www.nokia.com/poc/PoC WP A4.pdf

Motivation

Why Push-to-Talk over Bluetooth?

• If Bluetooth class 1 is used, range is up to 100m
• If multihop communication is used, the range can be extended further
• Push-to-Talk for free

Figure source: http://piconet.sourceforge.net/thesis/ma in.html

50 - 100m

Platform: Bluetooth PAN Profile

• Provides a platform for IP communications over Bluetooth
• ”Looks” like an Ethernet from the IP perspective
• Uses Bluetooth Devices Addresses (BD_ADDR) as MAC addresses
• Handles:
• IP address allocation
• IP routing & MAC address resolution
• Manual network formation
• Does not handle:
• Automatic network formation
• Networking with multiple piconets (e.g. scatternets)
• QoS mechanisms

Platform: Bluetooth PAN Profile

• Bluetooth protocol stack:
• BNEP (Bluetooth Network Encapsulation Protocol):
• Used for conveying of Ethernet packets

Figure source: Bluetooth Personal Area Networking Profile, Version 1.0, Bluetooth Special Interest Group, 2003, 65p. Figure source: Bluetooth Network Encapsulation Protocol (BNEP) Specification, Version 1.0, Bluetooth Special Interest Group, 2003, 55p.

PoB: General

• Features:
• Pre-arranged groups
• Transport Plane Protocols:
• IP/UDP/RTP
• AMR codec
• Sufficient throughput may be acquired if:
• A suitable Bluetooth base band packets is used,
• A suitable AMR mode is selected, and
• A suitable “AMR-frames per RTP-packet”-ratio is selected.
• (Please see following slides and thesis for more details.)
• Signalling
• Peer-to-peer over Bluetooth (no servers)

PoB: Throughput requirements

• Throughput requirements per link for different AMR modes with different

numbers of AMR frames per RTP packet:

• In worst case scenario calculations, the above figures need to be multiplied by 8.

(A device with 7 slaves acting as a bridge between piconets.)

PoB: Simulated Available Throughput

• Average and 90% percentile link throughputs for unidirectional traffic in

an environment with 1-500 fully loaded piconets:

100 kbps

Source: Zürbes, S., ”Considerations on link and system throughput of Bluetooth networks”, The 11th IEEE International Symposium on Personal, Indoor and Mobile Radio Communications PIMRC, Volume 2, September 2000, pp.1315– 1319.

PoB: Group Formation

• A group is defined by the BD ADDR:es of the group members devices.
• BD_ADDR:es can be exchanged via Bluetooth, SMS, IrDA, RFID etc:

1.

Jack creates a group by sending invitations to his friends Bill, Bob and Laura.

2.

Bill’s, Bob’s and Laura’s phones receive the invitation and query the user ”Accept PoB-group invitation from Jack?” If the user accepts, a message is sent to Jack containing the BD_ADDR of the user’s phone.

3.

Jack’s phone sends a message to Bill, Bob and Laura containing the group i.e. BD_ADDR:es of Jack, Bill, Bob, and Laura.

PoB: Network Formation

• Based on two principles:

1.

Only group members’ devices are allowed in the scatternet

2.

Loops are avoided

PoB: Network Formation

• A device maintains an

UNCONNECTED list of the devices that are not yet connected to the scatternet.

• The devices on the UNCONNECTED

list are Paged with a cyclic scheme with exponential backoff.

• If devices are added to or

removed from the scatternet, this information is flooded across the scatternet with UPDATE messages.

• When a new connection is

established, the connected device exchange information regarding devices connected to the scatternet.

• A method for detecting and

removing loops is also outlined.

PoB: Communication and Floor Control

• Communication:
• Communication itself is rather simple.The data can be flooded over

the entire scatternet, because it includes only group members and loops are disallowed.

• Floor control
• Based on sending Request to Speak (RTS) messages.
• If RTS:s collide, the one with the earlier time stamp is prioritized.
• A synchronization method is needed for the time stamping clocks. It is

based on simple broadcasting, because the accuracy requirement is rather lenient. (If two users press the PTT buttons of their devices within an interval of e.g. 10 ms, the users perceive the presses as more

• r less concurrent.)

Hybrid PoB + PoC

• It is also possible to create a service which uses PoB for reaching local

devices and PoC for reaching distant devices.

• Several ad-hoc PoC groups are needed if all group members participate

actively.

• Perspective of a device that is connected to a PoB Scatternet:

Hybrid PoB + PoC

• Perspective of a device not connected to the PoB Scatternet:

Conclusions and Future Research

• The thesis provides an outline for PoB and for hybrid PoB + PoC
• This novel solution is the technical contribution of this thesis
• If local voice communication can be provided for free with mobile

phones, the behaviour models of local communication may change

• PoC may act as a market driver for PoB (or vice versa!)
• The method may also be used for other purposes
• Gaming
• Shared folders
• Text based communication such as SMS, chat or IM
• Further research
• Simulations and/or testing
• Parameter optimization
• Security
• Restrictions of possible implementation platforms need to be

considered