Bluetooth Specification RFCOMM with Application Serial Port Emulation

Outline „ „ „

RFCOMM Specification LAN Access Profile Embedded Surveillance System with Built-in Bluetooth Protocol

What is RFCOMM doing ?

„

RFCOMM is used to transport the user data, modem control signals and configuration commands .

Bluetooth Protocol Stack

Overview „

„

The RFCOMM protocol provides emulation of serial ports over the L2CAP protocol. The RFCOMM protocol supports up to 60 simultaneous connections between two BT device.

RFCOMM Communication segment Application Device A

Communication Segment (BT link)

Application Device B

RFCOMM is intended to cover applications that make use of the serial ports of the devices in which they reside.

Device types „

Type 1 devices are the communication end points like computers and printers.

• Type 2 devices are those that are part of the communication segment like modems.

RFCOMM direct connect 具藍芽通訊能力的 裝置A(型一)

具藍芽通訊能力的 裝置B(型一)

Type 1 devices are the communication end points like computers and printers.

RFCOMM used with legacy COMM device 具藍芽通訊能力的 裝置A(型一)

具藍芽通訊能力的 裝置B(型二)

不具藍芽通訊能力 的裝置C

Type 2 devices are those that are part of the communication segment like modems.

BYTE ORDERING LSB

MSB

XXXXXXXX All binary number are in Least Significant Bit to Most Significant Bit order (Like TS 07.10 specification),reading from left to right.

Multiple emulated serial ports „

„

A Data Link Connection Identifier(DLCI) identifies an ongoing connection between a client and a server application. The DLCI is represented by 6 bits,but its usable value range is 2…61. (0 is channel; 1,62,63 are reserved)

Multiple emulation serial ports Emulation of multiple serial ports between two device Emulated serial ports 2

3

Emulated serial ports 61

2

3

RFCOMM

RFCOMM

L2CAP

L2CAP

Bassband

Bassband Radio

61

Emulating serial ports coming from two BT devices emulation of serial ports between multiple devices Emulated serial ports

Emulated serial ports 2

3

2

61

RFCOMM

3

RFCOMM

L2CAP

Bassband

61

Service interface description Port Emulation

Service Registration/Discovery Application

Read/Write

Control

Port interface (e.g. VCOMM)

Port Emunlation Entity Service registration/discovery

Data (TX,RX)

SDP

General control arameters Port parameter settings

RFCOMM L2CAP Bassband

RFCOMM Service interface

TS07.10 subset supported by RFCOMM FRAME TYPES Set Asynchronous Balanced Mode (SABM) command Unnumbered Acknowledgement (UA) response Disconnect Mode (DM) response Disconnect (DISC) command Unnumbered information with header check (UIH) command and response

TS07.10 subset supported by RFCOMM COMMANDS Test Command (Test) Flow Control On Command (Fcon) Flow Control Off Command (Fcoff) Modem Status Command (MSC) Remote Port Negotiation Command (RPN) Remote Line Status (RLS) DLC parameter negotiation (PN) Non Supported Command Response (NSC)

FRAME STRUCTURE of RFCOMM

Address 1 octet

Conttrol 1 octet

Length Indicator

Information

Integral number 1 or 2 octet of octets

FCS 1 octet

DLCI allocation with RFCOMM Command/response Direction C/R value server channels Command „ DLCI

Initiator

Responder

1

value space is divided between Responder Initiator 0 the two communicating devices using Initiator Responder 0 the concept of RFCOMM server Response Responder Initiator 1 channels and direction bit.

Set 1 in an octet = this octet is the last octet of the address filed Set 1 (Initiator) Set 0 = another octet of the address filed follows. Set 0 (Responder)

Format of control field „

„

P: poll bit set to 1 is to solicit(poll) a response F: final bit set to 1 is to transmit the response as the result of a poll command

Frame Types

1

2

3

4

5

6

7

8

SABM

1

1

1

1

P/F

1

0

0

UA

1

1

0

0

P/F

1

1

0

Multiplexor commands and responses are sent on DLCI 0 .They are used to control the RFCOMM connection. Address

Conttrol

Length Indicator

1 octet

1 octet

1 or 2 octet

Type (PN,RPN,RLS…)

Length

Information

FCS

Integral number of octets

1 octet

Value1

Value N

UA&DM of DLC Establishment „

„

If the responding station is ready to establish the connection it will reply a UA frame with F-bit set to 1. If it is not ready or unwilling to establish the particular DLC it will reply with a DM frame with the F-bit set to 1.

UA&DM of DLC Release „

„

Confirmation of the DLC release is signaled by the other station sending a UA frame with F-bit set to 1. If the station receiving the DISC command is already in a disconnect mode it will send a DM response.

DLCI allocation with RFCOMM server channels „

„

„

„

Server applications are assigned a server channel number in the range 1…30 The initiating device is given the direction bit =1 Server applications on non-initiating device:2,4,6,…,60 Server applications on initiating device:1,3,5,…,61

Start-up and closedown procedure „

„

Start-up procedure ¾Check only one RFCOMM session ¾Establish an L2CAP channel ¾Start the RFCOMM multiplexes Establish control channel(DLCI 0) Establish Data channel(DLCI X) Close-down procedure closing the multiplexes by sending a DISC command frame on DLCI X If it is the last link, the RFCOMM session will be release ,too.

Start – up procedure

1.Find out 5.Send SABM command on DLCI X RFCOMM 3.Send SABM command on DLCI0 Sever 2.Establish an L2CAP channel channel number 4.Wait UA or DM response on DLCI0 from 6.Wait UA or DM response on DLCI X SDP

Set up L2CAP connect

SABM Frame(DLCI 0) DM Frame (DLCI 0)

Disconnect L2CAP

Refusing an RFCOMM connection

Responding RFCOMM

Initiation RFCOMM

With PSM=0x0003

Set up L2CAP connect

DISC Frame (DLCI 0) Disconnect L2CAP RFCOMM channel timeout

Responding RFCOMM

Initiation RFCOMM

Timeout

SABM Frame(DLCI 0)

Set up L2CAP connect

Initiation RFCOMM

UA Frame (DLCI 0) PN Command PN Response SABM on (DLCI X) LMP Authentication UA Frame on(DLCI X)

Responding RFCOMM

SABM Frame(DLCI 0)

MSC FRAME Data on UIH Frame Message sequence chart for establishing an RFCOMM connect

Close – down procedure

3.Sending a DISC command on DLCI 1.Sending DLCI0X

2.Wait 4.Wait aa UA UA or or DM DM response response on DLCI X

Link loss handling 1.If an L2CAP link loss notification is received 2.The local RFCOMM entity is responsible for sending a connection loss notification to the port emulation/proxy entity for each active DLCI. 3.Then all resources associated with the RFCOMM session should be freed.

The RFCOMM communication model DCE (e.g. moden)

Legacy Application Port Emulation Entity RFCOMM

Port Proxy Entity RFCOMM

L2CAP

L2CAP

Bassband

Bassband

Type 1 Divice

Type 2 Divice

Port Emulation Entity The port emulation entity maps a system specific communication interface (API) to the RFCOMM services.

Port Proxy Entity The port proxy entity relays data from RFCOMM to an external RS-232 interface linked to a DCE.

An example Surveillance Endpoint

Surveillance Gateway

Start

RFCOMM

RFCOMM

L2CA_connect_req()

L2CAP LP_connect_req()

L2CAP LP_connect_rsp()

HCI Create_Connection

Bluetooth module

LP_connect_ind()

HCI Accept_Connection_request

Connection request

Bluetooth module

An example Surveillance Endpoint

Surveillance Gateway

RFCOMM

RFCOMM

L2CA_connect_cfm()

L2CAP LP_connect_cfm()

L2CA_connect_rsp() L2CAP_connect_rsp() L2CAP_connect_req()

HCI

L2CA_connect_ind()

L2CAP HCI

Connection Complete

Bluetooth module

ACL link

Bluetooth module

An example Surveillance Endpoint write()

RFCOMM L2CA_datawrite()

L2CAP

Surveillance Gateway UIH frame send_ua()

RFCOMM session send_sabm()

Logical Channel

read()

RFCOMM RFCOMM_dataread()

L2CAP

HCI_send_data()

L2CAP_receive_data()

HCI

HCI

ACL packet

Bluetooth module

ACL packet

ACL link

Bluetooth module

RFCOMM flow control „

„

The RFCOMM protocol contains flow control commands (FCon/FCoff) that operate on the aggregate data flow between two RFCOMM entities i.e. all DLCIs are affected. The Modem Status Command is the flow control mechanism that operate on individual DLCI.(FC bit)

Reference „ „

„

„

TS 07.10, ver 6.3.0, ETSI Specification of the Bluetooth System, Core V1.0 Specification of the Bluetooth System, Profiles V1.0 http://www.bluetooth.com

Service interface description „

The port emulation entity maps a system specific communication interface(API) to the RFCOMM services. The port emulation entity plus RFCOMM make up a port driver.

RETURN

Service Registration and Discovery

RETURN

LAN ACCESS Profile

1. SCOPE This profile defines LAN Access using PPP over RFCOMM . This profile define following three situations a). LAN Access for a single BT device b). LAN Access for multiple BT device c). PC to PC(using PPP networking over serial cable emulation)

2. Profile overview ME is the Management Entity which coordinates procedures during initialization, configuration and connection management.

2.1 protocol stack APP TCP&UDP IP PPP SDP RFCOMM

M E L2CAP

LMP Baseband

Data Terminal(DT)

APP TCP&UDP

PPP Networking PPP RFCOMM SDP M L2CAP E LMP Baseband

IP L A N

LAN Access Point(LAP)

LAN

2.2 Configuration & Roles LAN access point(LAP) 1. a BT device that provides access to LAN 2. provides the services of a PPP server. Data terminal(DT) 1.use the services of the LAP 2.typical devices acting as DT are laptops, notebooks.. 3.DT is PPP client that access LAN via LAP .

2.3 User requirements & scenarios „

1.LAN access by a single DT.

wireless Hub

Laptop computer

Data Terminal

LAN Access Point

LAN

2. LAN access by multiple DTs(The DTs can

also communicate with each other via the LAP(only if require services(e.g.DNS) are available on the LAN)) Data Terminal A

Laptop computer

wireless

Computer

Data Terminal B

Hub

LAN Access Point

LAN

3.

PC to PC connection.

Radio

Computer

PC A(DT)

Computer

PC B(LAP)

2.4 Profile Fundamentals 1. To find a LAP that is within radio range and providing PPP/RFCOMM/L2CAP service.

2.DT require a baseband physical link with the selected LAP. So need to establish it.

3.DT establishes a PPP/RFCOMM/L2CAP connection

4.Optionally LAP may use some appropriate PPP authentication mechanism(e.g.CHAP).

5.Negotiate IP address between LAP & DT.

6.IP traffic can flow across the PPP connection

7.Any time DT or LAP can terminate this connection

3

User Interface Aspects

When reading Generic Access Profile , DevA (the connection initiator) is equivalent to DT ; and DevB is equivalent to the LAP. The mandatory and optional requirement are define in Generic Access Profile

3.1 Security „

„

The LAP and DT will refuse any request to disable encryption. So BT pairing must occur as a means of authenticating the users.

3.2 ADDITIONAL PARAMETERS The following parameter is mandatory for the LAP. Optionally it may be configurable by the LAP administrator. • Single-user mode In this mode, either the DT or the LAP may be the master of the piconet. Single-user mode means that a single DT has exclusive access to a LAP. • Multi-user mode In this mode, the LAP must always become the master of the piconet. If the DT refuses to allow the LAP to become master, then the DT cannot gain access to the LAN.

4 APPLICATION LAYER Section Feature

Support in LAP

Support in DT

4.1

Initialization of LAN Access service

M

X

4.2

Shutdown of LAN Access service

M

X

4.3

Establish LAN Connection

C1

M

4.4

Lost LAN Connection

X

M

4.5

Disconnect LAN Connection

M

M

C1: Currently the LAP is not required to initiate a LAN connection establishment. In the future, a LAP may initiate a connection (e.g. as part of some form of LAP-initiated hand-off).

4.1INITIALIZATION OF LAN ACCESS POINT SERVICE

This operation involves setting the following parameters „ All the configurable parameters „ The required Bluetooth PINs and/or link keys. „ Any appropriate PPP configuration options (e.g. authentication, compression)can be configured. In order to ensure interoperability a LAP shall not require connecting DTs to perform any PPP authentication, until the LAP administrator has configured PPP authentication. When initialization is complete, the device will be able to accept PPP connections.

4.2 SHUTDOWN OF LAN ACCESS POINT SERVICE „ „

„

The PPP Server is shutdown All existing PPP connections are disconnected. The PPP layer disables or removes the PPP service entry from the Service Discovery Database.

4.3 ESTABLISH LAN CONNECTION

„

„

„

„

Normally the DT will initiate the establishment of a connection to the LAN. 1. The first step is to select a LAP and a suitable PPP/RFCOMM service that it provides. 2. Optionally, the DT user (or application) is allowed to enter a Bluetooth Authentication PIN or link key supplied by the application. 3. Optionally, the DT user (or application) is allowed to enter a username and password for PPP authentication. 4. When the user (or application) activates the connection, then a PPP application is started, to attempt to establish a connection to the selected access point/service

4.4 LOST LAN CONNECTION „

„

If the LAN connection is lost for any reason, then the DT user (or application) must be notified of connection failure. Optionally, the application may allow reestablishment of the connection to the same (or similar) LAP/service.

4.5 DISCONNECT LAN CONNECTION „

Either the LAP or the DT may terminate the LAN Connection at any time

5 PPP „

„

PPP/RFCOMM operation in this profile is similar to PPP operation in normal dial-up networking, except that this profile omits the use of AT commands; Alternatively, the LAP could be some kind of PPP proxy, where PPP packets are transferred to/from a PPP server somewhere else on the network.

Table 5.1: PPP capabilities Section Procedure

Support in LAP

Support in DT

5.1

Initialize PPP

M

X

5.2

Shutdown PPP

M

X

5.3

Establish PPP Connection

M

M

5.4

Disconnect PPP Connection

M

M

5.5

PPP Authentication Protocols

O

O

5.1 INITIALIZE PPP „

„

„

On the LAP, the existence of a PPP Server shall be registered in the Service Discovery Database. A device in the DT role does not register PPP in the Service Discovery Data-base. However, it is possible for a device to be both a LAP and a DT; therefore the device could register PPP in the Service Discovery Database as defined above.

5.2 SHUTDOWN PPP „

„

All existing PPP connections are disconnected. The PPP layer disables or removes the PPP service entry from the Service Discovery Database.

5.3 ESTABLISH PPP CONNECTION

Is RFCOMM session existing between the LAP and the DT?, YES

Using the Link Control Protocol (LCP) , the LAP and DT negotiate a PPP link.

NO

The device initiating the connection shall first initialize RFCOMM .

5.4 DISCONNECT PPP CONNECTION „

When the PPP connection is terminated, either by user intervention or automatically by the LAP, then the PPP layer takes the following steps:

1. Gracefully terminate the IPCP connections.This will cause the IP interface to be disabled.

2. Gracefully terminate the LCP connections

3. Disconnect the RFCOMM connection

5.5 PPP AUTHENTICATION PROTOCOLS „

„

Optionally, a LAP may be configured to use one or more of the PPP authentication protocols. These protocols allow a network administrator to control access to the network. Typically, the user needs to supply a username and password in order to gain authorization to use the PPP connection. If the authentication fails, then the PPP connection is normally dropped.

6 RFCOMM „

The speed of RFCOMM connections is not configurable by the user. RFCOMM will transfer the data as fast as it can. The actual transfer rate will vary, depending upon the other Bluetooth traffic on the baseband link. In particular, the connection speed will not be artificially held at some typical serial port value; e.g. 19200.

7 SERVICE DISCOVERY „

„

Each LAP will provide one Service Class for PPP/RFCOMM services. A LAP may contain multiple instances of this Service Class; e.g. access to multiple subnets. Where the access point provides more than one PPP/RFCOMM service, the service selection is based on service attributes. These services are made public via the SDP.

8 REFERENCES

8.1 NORMATIVE REFERENCES „ „

„ „ „

„

„

„

Bluetooth Baseband specification (See Volume 1, Part B) Bluetooth Logical Link Control and Adaptation Protocol Specification RFCOMM with TS 07.10 (See Volume 1, Part F:1) TS 101 369 (GSM 07.10) version 6.2.0. Bluetooth Service Discovery Protocol (SDP) (See Volume 1, Part E) Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 50, RFC 1661, Daydreamer, July 1994. Simpson, W., Editor, "PPP in HDLC Framing", STD 51, RFC 1662, Day-dreamer, July 1994. Serial Port Profile

„ „

„

„ „

„

„

„

8.2 INFORMATIVE REFERENCES Lloyd, B., and W. Simpson, "PPP Authentication Protocols", RFC 1334, Lloyd Internetworking, Daydreamer, October 1992. Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. Zorn, G., " Microsoft PPP CHAP Extensions", RFC 2433, October 1998. McGregor, G., " The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992. Pall, G., " The PPP NetBIOS Frames Control Protocol (NBFCP)”, RFC 2097, January 1997. " Mobile-IPv4 Configuration Option for PPP IPCP ", RFC 2290.

整合藍芽通訊協定之嵌入式 遠端多點監控系統

Embedded Surveillance System with Built-in Bluetooth Protocol

Introduction „

Motivation „ „ „

„

Size issue Cost issue Cable issue

Goal „ „ „ „ „

Embedded system Cost down Remote control ability Built-in Bluetooth protocol Applicable to IA(Intelligent Appliance )

Introduction(cont.) „

System Architecture

Introduction(cont.) „

Control Center(CC) „ „

„

Surveillance Gateway(SG) „ „ „

„

Surveillance Endpoints management Database management Communication gateway Forwarding surveillance command to SE Relaying acquisitive data to CC

Surveillance Endpoint(SE) „ „ „

Surveillance endpoint Data acquisition Emergency alarm

Hardware of Surveillance Gateway „ „

„ „ „ „

ARM7 CPU as main processor Serial interfaces for Bluetooth module and download RAM for data and OS requirement ROM for code storage LCD panel for debug information Modem module for communicate with CC

Hardware of Surveillance Endpoint „ „

„ „ „ „

8051 micro-controller as main processor Serial interface for Bluetooth connectivity RAM for data and OS requirement ROM for code storage Sensor interface for data acquisition LCD panel and keypad for configuration

Embedded OS „

Embedded OS on Surveillance Endpoints „ „ „ „

Base on 8051 platform Statically tasks scheduling Three system interrupt service routine(ISR) Five working tasks

Embedded OS Clock Task

Sensor Task

Comm. Process Task

Application Task

Configuration

Task

Scheduler Timer Interrupt Service Routine

UART External Interrupt Service Routine Interrupt Service Routine

Gateway Application „

Application on surveillance gateway „ „ „

Base on ARM Linux platform Running in user mode Four independent threads „ „ „ „

Modem thread Bluetooth thread Socket thread House-keeping thread

Control Center Application „

Application on Control Center „ „ „ „

Graphic user interface Surveillance database management Surveillance Endpoints management Use Remote Control Protocol

Embedded ARM Linux „

Why Linux? „ „ „ „ „ „

High performance High stability Low system resource request Highly embedded It’s free It’s open source

Embedded ARM Linux(cont.) „

Steps to build an ARM Linux system „ „ „ „

Building ARM Linux tool-chain Building ARM Linux kernel Building file system on ramdisk Download kernel and file system into target

Software architecture Application Task RFCOMM

GatewayApplication RFCOMM

L2CAP

L2CAP

HCI

HCI

Embedded OS

Control Center Application

Remote Control Protocol

Embedded Linux

Surveillance Endpoint Surveillance Gateway

Remote Control Protocol

Windows 98

Control Center

Bluetooth Protocol(cont.) „

Application Task

Protocol stack

GatewayApplication

RFCOMM

RFCOMM

L2CAP

L2CAP

HCI

HCI

Embedded OS

Remote Control Protocol

Embedded Linux

Surveillance Endpoint Surveillance Gateway

Control Center Application

Remote Control Protocol

Windows 98

Control Center

Testing Bluetooth module

Modem Ethernet Hub

Control Center

Surveillance Endpoint

Bluetooth module

Modem

Surveillance Gatewy

Telephone Switch