蓝牙设备Pair过程

蓝牙设备Pair过程

Friday, May 12, 2006 6:45:16 AM

bluetooth,Protocol

各家的设备，各自不同的SDP过程

Friday, April 7, 2006 2:59:22 AM

使用手机或PDA向另一个蓝牙设备发起OPP过程时，手机或PDA会通过SDP来寻找接收方的服务参数（最重要的就是RFCOMM channel）。下面列出了不同设备的SDP过程。从这之中可以看出不同厂家的开发人员对SDP的不同理解和应用。

K750c的SDP过程

06 00 01 00 24 36 00 03 19 11 1B 05 DC 36 00 18 09 00 01 09 00 04 09 00 09 09 01 00 09 03 10 09 03 11 09 03 12 09 03 13 00
07 00 01 00 03 00 00 00

06 00 01 00 1B 36 00 03 19 11 05 05 DC 36 00 0F 09 00 01 09 00 04 09 00 09 09 01 00 09 03 03 00
07 00 01 00 36 00 33 36 00 30 35 2E 09 00 01 19 11 05 09 00 04 35 11 35 03 19 01 00 35 05 19 00 03 08 0635 03 19 00 08 09 00 09 35 08 35 05 19 11 2F 09 01 00 09 03 03 08 01 00

disconnect L2CAP

06 00 01 00 10 36 00 03 19 11 05 02 A0 35 05 0A 00 00 FF FF 00
07 00 01 00 43 00 40 36 00 3D 35 3B 09 00 00 0A 19 76 06 26 09 00 01 19 11 05 09 00 04 35 11 35 03 19 01 00 35 05 19 00 03 08 0635 03 19 00 08 09 00 05 19 10 02 09 00 09 35 08 35 05 19 11 2F 09 01 00 09 03 03 08 00

1.首先: K750问了111B服务，也就是ImagingResponder服务，这是一个拍照服务吧？我们的设备当然没有这个功能。
            不过，明明发起的是OPP过程，为什么要问111B呢？
2.然后: K750问了1105服务，也就是OBEXObjectPush服务。这会儿，才问到点子上。我们的设备告诉了它，channel=06。可是K750c居然断开了L2CAP。
3.最后:K750c又问1105服务，但请求的属性则是0x0000到0xFFFF。在这些回答后，K750c终于在6号channel上连接了我们的设备。
看来索爱喜欢海阔天空的谈问题。

V3的SDP过程

06 00 01 00 19 35 03 19 11 05 00 80 35 0F 09 00 00 09 00 01 09 00 02 09 00 06 09 00 09 00
07 00 01 00 43 00 40 35 3E 35 3C 09 00 00 0A 19 76 06 26 09 00 01 35 03 19 11 05 09 00 02 0A 00 00 00 01 09 00 06 35 12 09 65 6E 09 00 6A 09 01 00 09 7A 68 09 00 6A 09 C8 00 09 00 09 35 08 35 06 19 11 2F 09 01 00 00

04 00 09 00 0C 19 76 06 26 00 80 35 03 09 C8 00 00
05 00 09 00 05 00 02 35 00 00

04 00 0B 00 0C 19 76 06 26 00 80 35 03 09 00 04 00
05 00 0B 00 1B 00 18 35 16 09 00 04 35 11 35 03 19 01 00 35 05 19 00 03 08 06 35 03 19 00 08 00

1.V3问了1105服务，和0x0002, 0x0006属性值。它们分别是ServiceRecordState，LanguageBaseAttributeIDList。但就是没有问0x0004属性。而前两个属性，一般都不问的。MOTO却问这个问题。
2.V3问起了语言问题C800，我们没有更多的信息回答它。
3.V3终于问了1105服务的0004属性。0004是ProtocolDescriptorList。
看来，MOTO是个文学家。

Palm TT的SDP过程
02 00 00 00 0E 35 09 19 11 05 19 01 00 19 00 03 00 01 00
03 00 00 00 09 00 01 00 01 19 76 06 26 00

04 00 01 00 0C 19 76 06 26 FF FF 35 03 09 00 04 00
05 00 01 00 1B 00 18 35 16 09 00 04 35 11 35 03 19 01 00 35 05 19 00 03 08 06 35 03 19 00 08 00

04 00 02 00 0C 19 76 06 26 FF FF 35 03 09 00 04 00
05 00 02 00 1B 00 18 35 16 09 00 04 35 11 35 03 19 01 00 35 05 19 00 03 08 06 35 03 19 00 08 00

04 00 03 00 0C 19 76 06 26 FF FF 35 03 09 00 04 00
05 00 03 00 1B 00 18 35 16 09 00 04 35 11 35 03 19 01 00 35 05 19 00 03 08 06 35 03 19 00 08 00

04 00 04 00 0C 19 76 06 26 FF FF 35 03 09 03 03 00
05 00 04 00 0A 00 07 35 05 09 03 03 08 01 00

04 00 05 00 0C 19 76 06 26 FF FF 35 03 09 03 03 00
05 00 05 00 0A 00 07 35 05 09 03 03 08 01 00

1. TT先是一个SSR问题，就是找服务句柄。服务的要求有1105（OPP），0100（L2CAP），0003（RFCOMM）。我们告诉TT，句柄是xxxxxxxx。
2. TT拿着句柄开始问SAR问题，就是找服务属性。它问了0004。好，问到点子上了。我告诉了它，是6，是6，是6。
3. TT又问了同样的问题。好问题，也不用问两遍吧。再回答。
4. KAO，又问一遍。
5. TT开始问起0303（Supported Formats List）属性了。另外，在SIG中0303为什么是Supported Formats List，也是Fax Class 2.0 Support呢？
6. 这个问题又问了一遍。
7. 断开L2CAP，不理我了。奇怪！我都回答了啊！
看来，TT是一个不喜欢与别人分享的人。


T39mc的SDP过程

06 00 00 00 10 35 03 19 11 05 FF FF 35 06 09 00 04 09 03 03 00
07 00 00 00 23 00 20 36 00 1D 35 1B 09 00 04 35 11 35 03 19 01 00 35 05 19 00 03 0806 35 03 19 00 08 09 03 03 08 01 00
工程师，绝对专业的工程师。只问一个问题，抓住要害。立刻得到答案。绝不多问一个问题。有点冷谦的意思。

2 comments

SDP的实现基本完成

Thursday, March 16, 2006 12:58:49 AM

bluetooth,Protocol, Program

经过一周多的辛苦工作，终于完成了SDP。虽然还要一些BUG，不过已经可以正常运行了。（加班的日子苦啊！）

Bluez，IVT和WIDCOMM（已经被CSR收购）的蓝牙软件在进行SDP发现时，实现的方式略有不同。Bluez使用的是SSAR，IVT和WIDCOMM使用的是SSR和SAR。但两者又有所不同。IVT是每发一个请求就发起一个L2CAP连接，收到回应后就断开。而WIDCOMM则是直到收到SAR的回应后才断开。

另外，强烈BS蓝牙SIG对SDP中的服务数据所设计的数据元（Data Element）格式。这个格式非常不便于存储，管理和组合。Bluez是按这个格式管理数据的，结果代码真得是很难读。我的SDP使用自己的格式存储，可是组合出回应PDU时又很麻烦。估计当初SIG设计这个格式时是为了减少空间占用吧。我就只看出有这个好处。呵呵！

No comments

开发的持续性

Monday, March 13, 2006 2:11:12 PM

Protocol,Program

协议栈的开发常常是持续的。因此，前期开发的往往是底层协议。在开发前期协议时，一定要注意为后期的高层协议开发做好准备。比如，准备好开发环境。这样就减少了后期高层协议开发的时间开销。

No comments

SDP事务和L2CAP连接生命期

Thursday, March 9, 2006 7:52:35 AM

bluetooth,Software, Program, Protocol

通常，SDP事务是由一系列请求和回应的PDU的交互组成的。在SDP层，SDP是无连接的数据报服务。连接是由L2CAP层完成的。SDP的职责是请求L2CAP层去完成。

因为SDP服务是无状态的。因此，当发送了一个请求后，就关闭L2CAP的连接。这样做将有害于SDP事务。而且导致必须花费资源去重新建立一个L2CAP层的连接。因此，SDP事务的L2CAP层连接保持的时间应该超过单个SDP PDU的传送时间。

通常，一个SDP会话不应该由服务端终止。然而，这样的事件仍是有可能发生的。如果发生了这样的事件，可以视为服务端关机，客户端清除与服务端会话产生的数据。这些数据据是不可用的。

No comments

字节序

Tuesday, March 7, 2006 6:53:11 AM

Program,bluetooth, Protocol

一个双字节整数0x0100，显然01是高字节，在内存中，01被放到高位地址。使用DEBUG看起来就是：
08001230: xx xx 00 01 xx xx xx xx xx .........
这种存放顺序就是little endian（小头派）

不过，如果存放顺序是：
08001230: xx xx 01 00 xx xx xx xx xx .........
这种存放顺序是big endian

Intel 的 Pentium CPU，AMD的CPU，还有ARM系列的CPU都属于小头派， Sun 的 Sparc CPU 属于大头派。大部分其它厂牌的 CPU 都是大头派。


蓝牙协议的PDU的字节序是不同。L2CAP是little endian，而SDP则是big endian。在使用ARM开发时，L2CAP层代码接收到的PDU可以分解后直接使用。而SDP层代码接收到的PDU在分解后还需要变换字节序。

No comments

Phone Book Access Profile

Sunday, February 26, 2006 2:40:47 PM

Protocol,bluetooth

2.4 规范基础
PCE只有在与PSE建立了安全的连接之后才可以使用PSE的服务.如果PCE是第一次使用PSE的服务,两个设备之间应该进行一次绑定过程.过程包含交换PIN码,建立一个link key,加密和服务发现.

PSE和PCE都可以发起这个绑定过程.但至少,PSE应该支持Inquiry以便发起绑定. PSE和PCE都应该支持Inquiry Scan Mode以便接受绑定.

2.5蓝牙安全
两个设备间应该使用GAP的认证过程来建立一个安全的连接.这个过程在GAP的5.1节有详细的描述.这个过程可以包括输入PIN码,建立一个link key. 在这个过程也可以使用一个固定的PIN码.

PBAP强制要求使用以下的几个蓝牙安全措施:

Bonding -- PCE和PSE应该在建立连接之前进行了绑定.安全模式的2或3应该是被使用的.

Encryption -- PCE和PSE的连接应该是加密的.

Bluetooth Passskey -- PCE和PSE禁止使用空密码.

而且,下面的措施也是被要求的,以符合PBAP:

Link keys -- 连接密码应该在一个PBAP连接中使用.

Encryption key length -- 密钥的长度至少为64位.为了提高安全性,在法律允许范围内使用最大的密钥长度是被鼓励的.

User confirmation -- 对于新接入的PCE,PSE应让使用者进行确认.

2.6顺应性
为了达到对本规范的顺应性,本规范所指出的所有强制要求都必须支持.

3.1PBAP对象和格式

3.1.1电话本存储
有多种存储电话本对象的方式. 一个典型的例子是GSM手机.它的电话本被存储在手机的内存中,另一个电话本则被存储在手机的SIM卡里.

3.1.2电话本对象
有五种电话本对象:

主电话本对象(pb)--对应用户电话本对象.如果PSE是一个手机,pb就是存储在手机里的电话本,或者存储在SIM卡里.
呼入电话历史记录(ich)--对应最近呼入的电话记录.电话记录的最大记录取决于设备的实现.
呼出电话历史记录(och)--对应最近呼出的电话记录.电话记录的最大记录取决于设备的实现.
未接电话历史记录(mch)--
所有电话历史记录(cch)--

pb,ich,och和mch的更多信息可以在IrMC文档中找到.cch是PBAP对IrMC的扩展.

3.1.3电话本对象表示形式
每个电话本对象有二种表示形式:

文件表示形式:电话本对象被表现为一个单个文件.它包含了相应的电话本实体.这种表示形式对应于IrMC的第二层信息交换.
文件夹表示形式:电话本对象被表现为一个虚拟的文件夹.文件夹中包含了相应的电话本实体.每个实体被表现为一个单独的文件.这种表示形式对应于IrMC的第三种信息交换.

注意:ich, och, mch和cch的文件夹表示形式都是对IrMC的扩展.

3.1.4电话本实体的格式
电话本对象的每一个单独的实体都是用vCard格式来表现的.PSE应该支持vCard 2.1和vCard 3.0,并按PCE请求的格式版本向PCE发送电话本实体.

无论使用什么版本的vCard格式,用于确定vCard编码格式的字符集属性都应是UTF-8.

无论什么时候,都应该在vCard中使用CHARSET属性参数以重载缺省的字符集, 在本规范中,UTF-8是该参数的唯一可被接受的值.

3.1.4.1呼叫历史的扩展
在och, ich, mch和cch文件夹中,每个呼叫的时间记录都可以使用IrMC定义的X-IRMC-CALL-DATETIME属性来表示.在本规范中,该属性引入了三个新的属性参数:
MISSED
RECEIVED
DIALLED
这三个参数被用来指明X-IRMC-CALL-DATETIME属性表示的时间戳对应的呼叫的类型.

比如,一个未接的记录是 2005年3月20号上午10点. 它被表示为:
X-IRMC-CALL-DATETIME;MISSED;20050320T100000

无论何时,这个三个新的属性参数都是被强烈推荐使用的.在从cch文件夹中接收vCard数据时它是特别有用的.

注意:不带时间是合法的:
X-IRMC-CALL-DATETIME;MISSED:

这种情况可能会在没有时间数据的设备中出现.存储的电话号码记录中没有时间数据.不过,在这种情况下,还是要增加呼叫的类型的数据.

3.1.5PBAP虚拟文件夹结构
按文件夹方式组织的电话本信息的架构如下图表示:

3.1.5.1句柄
PSE中所有的vCard都使用句柄来标识().这个内部的索引是8个十六进制串.

句柄的设计是基于在PBAP会话期间,句柄不会发生变化. 比如内部索引和每一个vCard的内容没有改变.如果由于某种原因,本规范的实现允许句柄在PBAP会话期间发生改变,那么该实现必须支持下面2个行为中的一个:

错误报告:如果任何一个句柄在PBAP会话时发生变化,PSE应该报告一个"Preconditon failed"的错误给正在进行读取操作的一方直到PCE重新更新vCard列表.

改变跟踪:PSE在PBAP会话期间,保持对每个改变进行跟踪.

3.1.5.2本地电话本:PB和SIM1
本地电话本内容放置在telecom文件夹中.如果PSE也包含了SIM卡的信息,SIM卡内的电话本信息应该被放置在SIM1/telecom文件夹中.

pb文件夹的0.vcf专用句柄是为用户手机卡保留的.无论PSE是否有这个号码的其它信息,它都要及时更新并至少包含本机号码.如果本机号码是无法识别的,index 0就必须是一个空vCard.index0不能够记录一个有别于PSE手机号码的数字.0.vcf必须在pb.vcf文件中表现.

位于pb文件中的vCards按句柄编号的升序方式排序.当有外部设备访问pb中的vCard列表,缺省的顺序应该是按句柄号的升序.

位于telecom和SIM1/telecom文件夹的vcf文件包含全部的相应的电话本对象的vCard, 并且可以在一个操作中将全部的对象发送出去.

3.1.5.3呼叫历史记录
每个呼叫历史记录的vCard的句柄都是独立的.即使在同一个文件夹里相同的电话号码,但它们的句柄也应该是不同的.

这些句柄同样按升序排序.最近的呼叫记录的句柄应该是1.vcf.顺序是按时间的.

强制要求PSE支持对历史记录的搜索和排列. 对搜索和排序的请求的vCard列表回应应该是时间顺序.

如果呼叫历史记录的电话号码可以与PSE中存储的的电话本内容相关连,PSE应该提供这些联系人信息.

3.1.6vCard列表对象(x-bt/vcard-listing)
vCard-listing对象是一个XML对象,并且缺省用UTF-8编码.而缺省的字符集可以被忽略.

vCard-listing对象按下面的DTD定义:

一个vCard-listing对象的例子:

3.1.6.1名字属性格式
vCard-listing的名字属性格式与vCard的名字属性相同.格式为:"LastNmae;FirstName;MiddleName;Prefix;Suffix".

4电话本访问特性
4.1PBAP特性
本规范有两个特性:下载和浏览.

2 comments

形式描述技术FDT的方法

Tuesday, January 24, 2006 9:08:38 AM

Protocol,FDT

随着网络服务要求的提高，网络系统的复杂性在协议方面体现出空间分布性、并发性、异步性、不稳定性和多样性，高质量的通信协议再也不可能靠工程直觉方法来设计了；协议工程（Protocol Engineering）用形式化的方法来描述在协议设计和维护中的各个活动，建立一套严格的协议设计方法，使协议开发的整个过程一体化、系统化和形式化，从而保证协议的完整性、正确性、安全性和可移植性。

形式描述技术FDT的特征
完整的语法和语义定义；
体系结构、服务和协议的可表达性；
协议重要特性的可分析性；
支持复杂协议的管理；
支持逐步求精的方法；
支持实现独立性；
支持协议生命期的各环节（描述、验证、实现、一致性测试、……）；
支持自动设计、验证、实现和维护方法。

FDT种类
状态变迁模型
有限状态机FSM
通信有限状态机CFSM
Petri网
程序设计语言模型
抽象程序
CCS，CSP
时态逻辑

国际标准 FDT－SDL
SDL (Specification and Description Language)：FSM + extensions 1976年由CCITT(ITU)颁布 ，一种基于扩展状态变迁和抽象数据类型的混合技术，被电信公司广泛用于描述电子分组交换系统，最近已发布了SDL-2000的新版本 。

国际标准 FDT－ LOTOS
LOTOS (Language Of Temporal Ordering Specification)：CCS+ADT 80年代ISO制订OSI参考模型时发布，1988年确立了最后的国际标准文本。 LOTOS提供形式语义，保证描述不存在二义性，便于分析和一致性测试理论的研究。LOTOS有二个组成部分，一部分基于过程代数，另一部分是基于ACT ONE的抽象数据类型。

国际标准－Estelle
Estelle(Extended State Transition Model Language)：EFSM + extended Pascal Estelle也是基于扩展的状态变迁模型，但使用PASCAL语法和数据类型，它有一个形式化的独立于实现的语义。 Estelle标准颁布以后， 一直到1994年，Estelle研究小组主要致力工具包的研制，1996年以后， Estelle标准又被改进了50多处，不过直到现在也没有见到Estelle 的升级版本。

SDL-2000是SDL-96和UML技术有机结合的版本， SDL-2000 = SDL-96 + UML

基于Petri网的FDT
Petri网理论是在并发的概念上建立起来的，它直观地表示了非确定性，可以用于表达不同抽象级上的系统概念。Petri网有一套成熟的数学理论工具，建立了许多分析技术，包括可达性分析、不变量分析(使用线性代数方法)、保持特性的变换(包括化简)、构造理论、形式语言理论、同步距离和网的分解和等价等。近几年人们的注意力集中在如何将代数的抽象数据类型，融合在高级网结构中，能够大大地提高描述协议和服务所用的高级Petri网系统的表示能力。 三种标准的FDT只支持协议工程的一至二个活动.
Estelle是一种过程语言，可以描述协议细节，用它描述的协议仅便于实现；
LOTOS描述协议实体的外部行为，不关心实体内部变化，描述的协议仅便于验证；
SDL是一种混合式的FDT，缺乏形式语义，缺乏分析技术。SDL-2000也只是吸收了UML的一些概念、方法，增加了面向对象的可视化设计功能，使之更好用，并没有从本质上提升SDL的分析能力 。

No comments