BLE 概览

BLE 概览

第一章 什么是低功耗蓝牙(Bluetooth Low Energy)

低功耗蓝牙是一项新技术,它不但是传统蓝牙(classic Bluetooth)的补充,同时也几乎是市面上最低功耗的无线技术了。虽然它从传统蓝牙借鉴了许多技术,但是低功耗蓝牙由于不同的设计目标和不同的细分市场,依然应该被视为一项不同的技术。

传统蓝牙被设计成串联不同世界的计算和通讯设备,把手机连接到笔记本上。然而,传统蓝牙最核心的应用是在手机与耳机类似的设备建立连接。随着需求的不断提升,传统蓝牙的速率也在不断加强。蓝牙从BR(Basic Rate)的最大物理层速率1Mbps,到在蓝牙2.0版本中添加Enhanced Data Rate(EDR)的3Mbps,再到3.0版本的Alternate MAC-PHY能达到数百兆每秒。

但是低功耗蓝牙走了完全不同的方向,不是提高速率而是优化功耗。


表1-1 总是增长的速率

已知的传统蓝牙技术不能满足纽扣电池,所以另外一个不同的方向被开辟出来了。虽然已经完全了解低功耗方面的需求了,另外一个方面也需要考虑。那就是数量的问题。低功耗蓝牙非常大量地部署的一种方法
就是价格低。例如,RFID(Radio frequency identification)标签能被大量应用的原因就是价格非常低,尤其是通过价格更贵一些的扫描器提供能量。

因此,低价对于低功耗蓝牙有着极其关键的意义。三个因素使这个设计能达到低价:

  • ISM 频段
    2.4Ghz 的ISM频段对于无线技术的设计和使用来说都是一个噩梦。它的传播特性非常弱,因为无线电的能量很容易被其他任何东西吸收,尤其是水。而人体又几乎是由水构成的。几乎可以说是这个缺点使这个频谱成为了全球都不需要牌照的无线频谱。免费意味着其他技术都将使用这个频谱,包括Wi-Fi。不需要牌照并不意味着没有任何限制,这些限制主要在限制设备的发射功率方面。然而,即使有这些限制,免费的频段也远远好过付费的。
  • IP 牌照
    当Wibree(蓝牙的前身)技术已经成熟到融合到一个已有的无线标准组织时,诺基亚(Nokia)可以选择这项技术给任何类似的组织。但是诺基亚没有选择WiFi联盟(Wi-Fi Alliance),而是声誉和许可政策都非常好的SIG(Bluetooth Special Interest Group)。这些政策意味着每个蓝牙设备的授权费都会非常低。
  • 低功耗
    设计一款低价设备最好的方式就是减少使用的材料,如电池等。更换电池得花钱,这不仅是需要重新买一块电池,再安装进去,也意味者设备不能正常工作的机会成本。

因此 低功耗的设计初衷就是能与纽扣电池协同工作——最小,最便宜且最容易适应各种类型电池的。但是,这也意味着你不能用它达到高速率数据传输、大量数据传输或者数据流传输。这也是低功耗蓝牙和传统蓝牙最重要的区别。

1.1设备类型

低功耗蓝牙的出现造就了两种类型的设备:双模设备和单模设备。双模设备既支持传统蓝牙也支持低功耗蓝牙。单模设备要么只支持低功耗蓝牙,要么只支持传统蓝牙。
很明显双模的设备可以与现有的蓝牙设备进行通讯。很明显低功耗蓝牙的单模设备不能与现有的蓝牙设备进行通讯,但是它依然能够与其他的低功耗蓝牙的单模设备和双模的蓝牙设备通讯。传统蓝牙单模设备不能与低功耗蓝牙单模设备通讯,但是传统蓝牙可以与双模设备或者传统蓝牙单模设备通过BR/EDR通讯。

表1-2 单模与双模设备的兼容性

1.2 设计目标

在学习任何技术的时候,总是会有一个首先被提到:设计者如何优化这项技术。许多技术都是有一两项擅长的地方和更多的是不擅长的。在决定这一两项目标的时候,对于这项技术会有一个更好的理解。

蓝牙的主要目标包括:

  • 全球可用
  • 低价
  • 健壮
  • 短距离
  • 低功耗

其中低功耗蓝牙的功耗是其主要设计目标。从物理层到应用层全面全部都由Bluetooth SIG设计,以达到最好的低功耗效果。

1.3 术语

AFH(Adaptive Frequency Hopping) 只使用一部分信道的技术。这能有效避开那些被长时间占用的信道。

Frequency Hopping 两个器件之间通讯使用多个信道。在一个时间使用一个信道,并且按照事先定义好的序列选择信道。

第二章 基本概念

低功耗蓝牙不是对传统蓝牙的优化,而是对新的细分市场重新设计的无线标准。这个细分市场要求再一秒到几天的时间内,器件之间的通讯只有少量的数据。这包括了一些控制和检测应用,如检测窗户是不是开着,根据电价的波动开关一些电器,或者给电视机换台。

2.1 纽扣电池

纽扣电池是低功耗蓝牙的主要设计目标。这样的电池有着非常严格的使用条件。
<div align="center">图2-1 纽扣电池 </div>


图2-1 纽扣电池

如图2-1所示是一块纽扣电池,CR2032。"CR"表示这是3伏电压的锂锰电池。"20"表示它是直径20mm,32表示它是高度3.2mm。
CR2032的典型电池容量是230mAh,还不够一个成人的身体使用20s。但是低功耗蓝牙却要使用几年时间。即使电池容量已经是230mAh这么小了,有时候仍然无法使用里面的全部能量。再温度为0度时,可用的电池容量只有正常室温的百分之八十。
此外,电池还不能过量使用,也就是说使用纽扣电池时,不能超过它的峰值电流,否则会损坏电池。如果长时间大电流使用电池会使电池的容量减少。典型的电流峰值是15mA。所以,优秀的设计应该在使用大电流后,给电池留下恢复的时间。
最后,电池自放电也应该考虑到。即使器件不使用电池,电池也会放电的。当电池很少使用时,漏电流会占使用电池总量很重要的一部分。

2.2 时间就是能量

另外一个重要的概念就是时间就是能量。即使器件只是检查是不是需要收发数据依然要消耗能量。所以,减少时间去做有用的事就很重要了。

可靠地发现器件至少需要两个器件:一个器件搜寻其他器件,另外的器件处于可被发现的状态。在低功耗蓝牙中,处于可被发现状态的器件需要隔几秒就发送三次短消息。如果想知道是否有其他器件愿意与它通讯,他就要在广播之后立即开始监听。
至于为什么是发送三次呢,这其实是可靠性和低功耗之间的折中。如果只在一个信道发送一次,那么由于发送的次数少,功耗必然降低了。但是如果这个信道被干扰,整个系统都将崩溃。如果是16个信道,每个信道发送一次,那么就会能量消耗就会很大了。
哪个器件发送,哪个器件接收也都是经过深思熟虑的。搜寻正在发送的器件需要听很长时间;这么做会消耗很多的能量,这部分工作将会放在有更多能量的器件上完成。
数据包很短。使用短数据包有三个原因:
第一,使用高效的编码,短包发送相同数量的数据,但是更快,且使用更少的能量【这点我不太能理解】。第二,严格使用短包,使得器件不需要经常重新校准参数。因为器件在发送和接收的过程中温度会上升,导致改变芯片的一些参数,进而使得频率偏移。使用短包就让器件没有足够的时间升温了。此外使用短包也使得芯片的峰值电流降低了一些。最后,短包意味着间隔性地使用电池,这给纽扣电池提供了更好的恢复时间。那么就可以最大限度地利用纽扣电池的能量了。

2.3 内存很贵

大家都知道电脑的内存越大,电脑也就越贵,同时内存也是需要消耗能量的。低功耗蓝牙每一层的设计都在考虑如何降低内存的使用。
例如,链路层(Link Layer)的数据包很小,能降低收发数据包的内存需求。属性协议层(Attribute Protocol Layer)不处理超过23个字节的数据包。此外它还不保存通讯间的状态。
当需要多做多件事的时候,就需要多种协议的支持。但是低功耗蓝牙只有一种协议。属性协议 (Attribute Protocol)用于名字发现,服务发现,读写信息等。只使用一种协议,那么多种协议的开支就节省下来了。

2.4非对称设计

几乎低功耗蓝牙的每一层的设计都是非对称的,因为能量少的器件应该少干活。
在链路层,从机(slave)不需要做任何复杂的事,而主机(master)需要处理时间,自适应跳频,加密等等一些复杂的事情。从机只做主机告诉它做的就好了。
在属性协议层有两种器件:一种是服务端(server),一种是客户端(client)。服务端保存了数据,客户端向服务端请求数据。服务端像链路层的从机一样,只做告诉它做的。而服务端就需要知道服务端有哪些数据,以及如何利用它。
即使是安全架构也是非对称的。主机需要做记住密钥,绑定信息等等复杂的工作,而从机就很简单了。能量不同,责任也不同。非对称设计有效地提高了那些能量短缺器件的工作时间。

2.5 为成功而设计

为成功而设计意味着每个进到拥挤的地铁或者公交的人都能够操作他们的低功耗器件。这意味即使几千个器件都处在几米范围内,它们依然能够正常工作。而且低功耗蓝牙没有传统蓝牙的7个从机的限制。低功耗蓝牙有着非常好的安全机制,这包括了数据的加密和隐私的保护。在连接状态时使用private address可以有效避免被追踪。
为了保障数据的完整性,所有的数据包都有一个强的循环冗余校验(CRC)。如果还是不放心,那么再属性协议层提供了一种先验证,再写入的操作方法。

2.6 任何事物都有状态

低功耗蓝牙的另外一个基本概念是任何事物都有状态。这个状态是通过使用属性服务端的属性协议实现的。状态可以是任何东西:当前的温度,器件的电池状态,器件的名字等。
状态不只能读出,也能写入。例如设置加热器的温度。通过使用准确的状态机属性,器件的状态可以清晰地表现出来。这使得客户端可以随时断开连接,因为当重新连接的时候,当前状态有可以很快被读出。
有些状态是可能很快发生变化。服务端和客户端之间可以使用直接通知的方式来传递信息。每当电池状态发生变化时就会通知客户端,而客户端不用一直轮询着电池的状态。

2.7 客户端-服务端架构

在设计低功耗蓝牙的时候,设备联入到英特网的的问题就被考虑到了。把IP协议栈放到每一个器件本来是可以实现的,这样所有的器件通过IP协议都是可见的了。但是即使是最简单的IP协议栈对于低功耗蓝牙来说,它所需要的内存和能量也过大了。
而客户端-服务端的架构使设备的联网成为了可能。客户端可以直接连接到服务器,或者可以通过网关连接到服务器。而服务端只是一个数据仓库,它并不管客户端是谁。

2.8 模块化的架构

低功耗蓝牙是基于Generic Attribute Profile架构的,具备非常优秀的扩展性。为此Bluetooth SIG,成立的一个特别的架构工作组致力于模块化服务架构。他们把一些原子性的行为封装成服务,这些服务之间又可以相互引用。例如一个电池服务自身有一个温度传感器,那么它就可以引用一个温度服务;这个温度服务也可以被一个家用的加热器使用。
另一个特点是,器件上的服务并不是直接与指定的框架(profile)交互。框架(profile)会请求获得一个器件的许多服务,而它可以选择把这些服务组合起来。
这样高灵活性的模块化架构使得低功耗蓝牙生态系统没那么容易过时。

2.9 十亿是少量

一项新技术获得市场青睐会碰到很多严峻的考验。一项技术成功,需要足够低价;而为了能够低价,就需要巨大的出货量;巨大的出货量就需要它能取得成功。今天单一最大出货量的消费电子就是手机,任何能够融入到手机上的技术都能成功。传统蓝牙就是一个例子。

这项技术有机会再几年内就达到十亿的出货量。有意思的是,它还创建了一个巨大的周边商品市场。

2.10 无连接模型

传统蓝牙几乎就是为了取代有线而诞生的:耳机线,鼠标线,文件传输线。这意味着即使花上一些时间建立一次链接也是无关紧要的,因为这个链接会保持几分钟,几个小时,甚至几天。几秒钟的延迟,完全是微不足道的。但是低功耗蓝牙完全改变了这些。
低功耗蓝牙的另一个基本概念是,连接(保持连接)是短暂的。当我们需要做一些事情或者检查一些东西,我们快速创建一个连接,做完需要做的事情,然后断开连接。每5分钟发送一次通知的器件,一天工作的时间不到一秒钟。这意味着,器件的无线收发器有99.999%的时间是关着的。建立连接过程中的任何延迟都可能产生巨大的能量消耗。

低功耗蓝牙从建立连接,发送数据,到断开连接大约只要3毫秒。

第三章 架构

如图3-1所示的是蓝牙的架构,主要分为了三个部分:controller,host,和application。controller主要完成无线信号的收发以及把这些信号转换为有用的信息。host主要是一个负责两个或者多个器件之间通讯。应用层就利用host和controller实现一个应用的实例。


图3-1 蓝牙架构

3.1 Controller

controller通过天线与外部时间建立联系;通过Host Controller Interface与host完成协作。

3.1.1 物理层(Physical Layer)

物理层使用2.4GHz的无线收发器完成工作。对于很多人来说,物理层是很神秘的。从本质上讲,它只是电磁辐射的简单收发。电磁波在一定的频率上,能通过改变振幅,频率,相位传递信息。低功耗蓝牙采用了GFSK(Gaussian Frequency Shift Keying)调制方案。

FSK(Frequency Shift keying)说的是无线收发器通过少量地上下改变频率来发送0和1.如果频率从一边很快变化到另一边,那么就会有一个脉冲能量延展到更宽的频率上去。所以,这时候就需要一个过滤器阻止能量散播到其他频率。在GFSK上,使用的过滤器就像是一个高斯曲线(Gaussian curve)。

调制指数描述了偏离中心频率多少的频率如何使用。当一个无线信号被发送了,高于中心频率185kHz的频率表示1,而低于中心频率185kHz的频率表示0。
2.4GHz频段被分为了40个独立的信道,每隔2MHz一个。物理层每微秒发送一个比特(bit)。

3.1.2 直接测试模式(Direct Test Mode)

直接测试模式是为了测试物理层而设计的。大多数的无线协议没有测试物理层的标准方法。这导致了一个问题,那就是不同公司都用自有的方式测试物理层。毫无疑问,这增加了成本。

直接测试模式使得测试人员可以给物理层发送指令,使它发送一段数据包或者接收一段数据包。测试人员就能分析接收到的数据包,进而确定是不是符合规范。直接测试模式也可以用于产线产品测试和频率校准。例如:发送指令给物理层发送指定频率的波形,然后通过仪器测试实际发送的信号频率,最后调整无线收发器到正确的频率。

3.1.3 链路层(Link Layer)

链路层也许是低功耗蓝牙架构中最复杂的一层了。它需要负责广播(advertising),扫描(scanning),创建和维持连接(connnection)。同时它还要保证数据是正确的结构,正确的校验值,正确的加密。为了完成这些,有三个基本概念:信道(channels),数据包(packets),步骤(procedures)。
链路层的信道有两种:广播信道(advertising channels)和数据信道(data channels)。很明显,那些不处于连接状态的器件使用广播信道。总共有三个广播信道,(再提一次,这是低功耗和健壮性的折衷)。器件使用这些信道广播数据,广播它们的可连接性(connectable)和可发现性(discoverable);扫描和发起连接。当建立连接后才会用到数据通道。数据通道可以被加密(encrypted)和认证(authenticated)。

任何数据的收发都有一定的包格式。广播信道和数据信道的基本结构都是一致的,如图3-2

图3-2 链路层包结构

8-bit的前导码(preamble)用于时间同步和设置收发器的自动增益。32-bit的访问地址(access address)在广播包中是固定的,而在数据包中则是随机的。8-bit的头部(header)用于描述数据包的内容;8-bit的长度(length)则用于描述负载长度。负载最长可以达到37字节,即296 bits。24bits的循环冗余码(CRC)用于保证接收的数据包没有错误。

3.1.4 Host/Controller Interface

host使用Host/Controller Interface(HCI)与controller完成通讯。HCI包含了两个部分:逻辑接口(logical interface)和物理接口(physical interface)。
逻辑接口定义了命令(commmands),事件(events)以及相关的行为。逻辑层可以通过物理方式传达,或者通过controller上的应用编程接口(API)。

3.2 Host

3.2.1 Logical Link Control and Adaptation Protocol(L2CAP)

L2CAP是低功耗蓝牙多路复用层。这一层定义了两个基本概念,即L2CAP通道和L2CAP信号命令.L2CAP的每一个通道都是独立的,并且有自己的流控。

低功耗蓝牙只是用固定的通道:一个用于信号通道,一个用于Security Manager,一个用于Attribute Protocol。帧格式如图3-3,包含两个字节的长度,两字节的通道标签。


图3-3 L2CAP帧格式

3.3.2 Security Manager Protocols

Security Manager定义了配对(pairing)和密钥分发(key distribution)协议。配对是一个器件与另一个器件之间建立信任的过程,一般通过认证完成。配对成功后一般随后就是加密链接并分发密钥。完成密钥分发后,这两个器件在下次重连时就会很快建立。

3.2.3 The Attribute Protocol

属性协议(Attribute Protocol)定义了一系列访问对方器件数据的规则。这些数据就是属性客户端能读和写存储在属性服务器上的“属性”。客户端给服务端发送请求,服务端对这个请求做出响应。服务端可以使用这些请求命令找到服务器上所有的属性,并读写它们。属性协议定义了六种类型的消息:1.客户端发送给服务端的请求;2.服务端对于客户端请求的回应 3.客户端发送给服务端的命令,但是服务端没有响应 4.服务端主动发送给客户端的通知(notification) 5.服务端主动发送刚给客户端的指示(indication) 6.客户端响应服务端指示的确认(confirmation)。 所以,客户端和服务端都可以发送消息,而消息可以是需要响应的也可以是不需要响应的。

属性是有地址和标签的数据。每一个属性都有唯一的句柄(handle)用于识别属性,一个类型,和一个值。例如,一个属性的类别是Temperature,它的值是20.5°C,它的句柄是0x01CE。

属性协议也定义了属性的许可权限:只读或者只写一个属性的权限,或者只有客户端经过认证或者被服务端授权后才能访问属性的值。你不能直接发消息取得一个属性的权限;但是你可以发送请求,但是会得到一个有错误的响应,通过这个查询这个错误就知道为什么没有成功了。

属性协议自身几乎是无状态的。每一个单独的交互都不会在服务端保留状态。这意味着该协议只需要很少的内存。但是有一个例外:prepare and execute write requests。使用这个请求时,服务端将存储一段数据,然后再一次执行。

3.2.4 The Generic Attribute Profile

一般属性框架(The Generic Attribute Profile)在属性协议之上。它定义了属性的类型和属性如何使用。一般性属性框架引入了许多概念,包括:"特征(characteristics)","服务(services)",服务之间的"包含(include)"关系,特征的"描述符(descriptors)"。它也定义了用于发现服务,特征,服务间关系,读写特征值的步骤。

服务是器件的一些原子行为的不可变封装。这实在是一个很复杂的解释,但是却是一个容易懂的概念。不可变(immutable)当一个服务发布后,它就不能修改了。一旦服务的行为更改了,其他设置就需要花时间做相应修改,这就走向了低功耗蓝牙基本理念之一——无连接(connectionless)的对立面。

封装(encapsulation)意味着简洁地表现一些特性。一个服务的所有内容都是通过属性服务器承载和表达的。一旦你知道了属性服务器上的一个服务的范围,你就能知道服务封装的内容了。原子性(Atomic)意味着更大系统中的单一不可减少的组件。原子性的服务非常重要,因为服务越小,能被重用的可能性就越大。如果我们创建了一个包含了众多行为的复杂服务,那么这个服务被重复利用的可能性就降低了很多。
行为(behaviour)是说对于情况或者刺激的反应动作。对于服务来说,行为是当你读或者写一个属性时,将发生什么;或者是什么导致属性发送通知给客户端。明确地定义行为对于相互的可操作性非常重要。如果一个服务的行为没有明确定义,那么每一个客户端在与这个服务交互时就有可能出现不同的动作。服务对于不同的客户端也可能有不同的反应。更可怕的是,不同器件的相同服务也会不同。因此,明确定义的行为是可测试的,即使对于错误的相互操作,也提升了互操作性。

服务关系(service relationships)是复杂行为的关键。服务原生都是原子性的。复杂的行为不应该由单一的服务表示。例如,一个器件可以通过展示的温度服务测量室内温度。这个器件可能是通过电池供电的,所以它也会显露出一个电池服务。然而,如果这个电池有一个温度传感器,我们就能在器件上显露另一个温度服务。第二个温度服务需要与电池相关,那么客户端就能知道它们之间的关系了。如图3-4所示:


图3-4 复杂的服务关系

为了适应服务间的复杂行为和关系,服务分为了两类:首要服务(primary services)和次要服务(secondary services)。服务是什么类型一般不依赖服务本身,而是依赖于如何使用这个服务。在用户的角度,首要服务展现出了这个器件是做什么的。而次要服务是用来帮助主要服务或者次要服务完成相应的工作。在上一个例子中,电池服务是一个首要服务,同时它还引用了一个次要服务(温度服务)来完成一部分工作。另外一个温度则是一个首要服务。

3.2.5 The Generic Access Profile

一般访问框架(The Generic Access Profile)定义了器件是如何发现,连接和呈现有用的信息给用户的。它同时也定义了器件之间如何建立永久的关系,叫做绑定(bonding)。为了实现这些,这个框架定义了器件如何变成可发现(discoverable),可连接(connectable)和可绑定(bondable)。它也定义了这些器件如是使用步骤(procedures)发现其他器件,连接到其他器件,读取其他器件的名字,绑定他们。
这一层也通过使用可分解的私有地址(resolvable private address)引入了隐私的概念。

3.3应用层

一般属性框架(The Generic Attribute Profile)定义如何为把属性组合成特征和服务,应用层则定义了如何使用这些属性。

3.3.1 特征(Characteristics)

特征是有UUID(Universally Unique Identifier)的数据。特征被设计成可复用的,因此就没有行为。只要添加了行为,就限制了它的复用。最有趣的是它使用了更适合电脑理解的格式,而不是适合人类理解的文本。

3.3.2 服务(Services)

一个服务是一些特征和它们相关的行为组合在一起的人类可读的规范。服务只定义了服务端上这些特征的行为,但是没有定义客户端的行为。

一个服务可以包含其他服务。父类服务只能定义它们包含的服务,而不能修改这些被包含服务中的特征和行为。但是可以描述这边被包含的服务是如何相互作用的。

服务并不描述如何如何找到和使用这些服务。服务只描述当一个特征被读或写时,将发生什么。

3.3.3 框架(Profiles)

框架是一个使用实例或者应用的终极实例。框架定义了客户端如何找到服务,找到服务的特征,以及如何使用这些服务完成最终的应用。
从框架到服务是多对多的映射,如图3-5。一个服务可以被多个框架使用来完成器件的行为。服务的行为与哪个框架在使用这个服务没有任何关系。


图3-5 框架与服务的复杂关系
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,736评论 4 362
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,167评论 1 291
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,442评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,902评论 0 204
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,302评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,573评论 1 216
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,847评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,562评论 0 197
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,260评论 1 241
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,531评论 2 245
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,021评论 1 258
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,367评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,016评论 3 235
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,068评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,827评论 0 194
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,610评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,514评论 2 269

推荐阅读更多精彩内容

  • Guide to BluetoothSecurity原文 本出版物可免费从以下网址获得:https://doi.o...
    公子小水阅读 7,614评论 0 6
  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 134,100评论 18 139
  • 超低功耗 本文作为《LPWAN市场报告》中的一部分,继续上篇 在LPWAN的应用中主要是以LPWAN模块使用为主,...
    芯资讯阅读 1,460评论 1 1
  • 文章图片上传不正常,如需文档,可联系微信:1017429387 目录 1 安装... 4 1.1 配置探针... ...
    Mrhappy_a7eb阅读 6,158评论 0 5
  • 不知不觉中,训练已经度过了二分之一的时间,虽然每一天都很忙、完成作业的压力也很大,但是,每当自己挑战了自己的不舒适...
    Nicole_dd09阅读 154评论 0 0