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 • 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 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: 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: 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 • Codec: AMR
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- of-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 50 - 100m Figure source: http://piconet.sourceforge.net/thesis/ma in.html
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: Figure source: Bluetooth Personal Area Networking Profile, Version 1.0, Bluetooth Special Interest Group, 2003, 65p. • BNEP (Bluetooth Network Encapsulation Protocol): • Used for conveying of Ethernet packets 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: Jack creates a group by sending invitations to his friends Bill, Bob and Laura. 1. Bill’s, Bob’s and Laura’s phones receive the invitation and query the user 2. ”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. Jack’s phone sends a message to Bill, Bob and Laura containing the group i.e. 3. BD_ADDR:es of Jack, Bill, Bob, and Laura.
PoB: Network Formation • Based on two principles: Only group members’ devices are allowed in the scatternet 1. Loops are avoided 2.
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 or 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
Recommend
More recommend
