WO2014063514A1 - 一种通过蓝牙广播数据的方法及蓝牙设备 - Google Patents

一种通过蓝牙广播数据的方法及蓝牙设备 Download PDF

Info

Publication number
WO2014063514A1
WO2014063514A1 PCT/CN2013/081217 CN2013081217W WO2014063514A1 WO 2014063514 A1 WO2014063514 A1 WO 2014063514A1 CN 2013081217 W CN2013081217 W CN 2013081217W WO 2014063514 A1 WO2014063514 A1 WO 2014063514A1
Authority
WO
WIPO (PCT)
Prior art keywords
bluetooth device
sdp
service
data
preset service
Prior art date
Application number
PCT/CN2013/081217
Other languages
English (en)
French (fr)
Inventor
薛涛
杜军朝
刘惠
冯河
刘畅
毛磊
刘玺
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2014063514A1 publication Critical patent/WO2014063514A1/zh

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04BTRANSMISSION
    • H04B5/00Near-field transmission systems, e.g. inductive or capacitive transmission systems

Definitions

  • the present invention relates to the field of Bluetooth communication technologies, and in particular, to a method for broadcasting data through Bluetooth and a Bluetooth device.
  • Bluetooth technology As a short-range wireless connection technology, Bluetooth technology is gaining wider and wider application and is receiving more and more attention. Bluetooth applications can be seen in both industrial control and mobile terminals.
  • the Service Discovery Protocol is based on a client/server architecture that allows two Bluetooth devices to recognize and establish a connection.
  • the basic functions of SDP include: providing customers with the function of searching for services by service attributes; providing functions for discovering services by service classes; providing service browsing functions; providing decision mechanisms for effective or effective services; providing decision mechanisms for device failure or service failure Provides the ability to uniquely identify services, service classes, and service attributes; discover services on another device without third parties; can be used for simple devices; provide incremental access to service information mechanisms; support cache of service discovery information, improve Discover the efficiency or speed of the process; be able to transmit independently; use the Logical Link Control and Adaptation Protocol (L2CAP) as the transport layer protocol; be able to discover and use services that access other service discovery protocols; Master device license, support for the creation and definition of new services.
  • L2CAP Logical Link Control and Adaptation Protocol
  • An object of the embodiments of the present invention is to provide a method for broadcasting data through Bluetooth and a Bluetooth device, which can implement Bluetooth-based data broadcast transmission.
  • a method for broadcasting data through Bluetooth is applied to a wireless transmission network including a plurality of Bluetooth devices, the method comprising:
  • the first Bluetooth device obtains data to be broadcasted;
  • the first Bluetooth device writes the data to be broadcast to the preset service record of the SDP server end of the Bluetooth service discovery protocol of the device, where the preset service record corresponds to the preset service;
  • the first Bluetooth device sends the preset service record to the second Bluetooth device, where the second Bluetooth device obtains the data to be broadcast carried therein.
  • the preset service record includes an attribute list, and the to-be-broadcast data is written in an attribute value of the attribute list;
  • the step of the first Bluetooth device transmitting the preset service record to the second Bluetooth device includes: receiving, by the first Bluetooth device, an SDP service query request for the preset service that is sent by the second Bluetooth device;
  • the first Bluetooth device returns a handle of the preset service to the second Bluetooth device according to the received SDP service query request;
  • the to-be-broadcast data is obtained in the list.
  • the method further includes:
  • the first Bluetooth device When the first Bluetooth device writes the data to be broadcast to the preset service record of the SDP server of the device, the first Bluetooth device further maintains the list of Bluetooth devices through which the data to be broadcast passes in the preset service record;
  • the first Bluetooth device After receiving the SDP service query request for the preset service sent by the second Bluetooth device, the first Bluetooth device further determines whether the second Bluetooth device exists in the Bluetooth device list, and if yes, rejects the SDP service query request. If not, returning a handle of the preset service to the second Bluetooth device.
  • the obtaining, by the first Bluetooth device, the data to be broadcast comprises: the first Bluetooth device receiving data to be broadcast input by the user.
  • the step of the first Bluetooth device obtaining data to be broadcast includes: The first Bluetooth device sends an SDP service query request for the preset service to the third Bluetooth device;
  • the first Bluetooth device sends an SDP service attribute request carrying a handle of the preset service to the third Bluetooth device;
  • the first Bluetooth device receives a preset service record returned by the third Bluetooth device for the received SDP service attribute request, and extracts the to-be-broadcast data from the attribute list of the service record.
  • a Bluetooth device including a Bluetooth service discovery protocol, an SDP server and an SDP client, and a data obtaining unit and a recording unit, wherein:
  • the data obtaining unit is configured to: obtain data to be broadcasted
  • the recording unit is configured to: write the data to be broadcast obtained by the data obtaining unit to a preset service record of the SDP server, where the preset service record corresponds to a preset service;
  • the SDP server is configured to: send the preset service record to the another Bluetooth device according to an SDP request of another Bluetooth device for the preset service, where the another Bluetooth device obtains the carried therein The data to be broadcast.
  • the preset service record includes an attribute list, and the to-be-broadcast data is written in an attribute value of the attribute list;
  • the SDP server is configured to send the preset service record to the another Bluetooth device according to an SDP request of another Bluetooth device for the preset service according to the following manner:
  • the recording unit is further configured to: when the data to be broadcast is written to the preset service record of the SDP server of the device, maintain the list of Bluetooth devices that the data to be broadcast passes through in the preset service record;
  • the SDP server is further configured to: after receiving the SDP service query request for the preset service sent by the second Bluetooth device, determine whether the second Bluetooth device exists in the Bluetooth device list, and if yes, reject the The SDP service queries the request; if not, returns a handle of the preset service to the second Bluetooth device.
  • the data obtaining unit is further configured to: receive data to be broadcast input by the user.
  • the SDP client is configured to:
  • the data obtaining unit is further configured to: obtain the to-be-broadcast data from the SDP client.
  • the method for broadcasting data through Bluetooth and the Bluetooth device provided by the foregoing technical solution can transmit data between Bluetooth devices without establishing a connection; and, also, the limitation of the Bluetooth transmission distance can be broken. Broadcast information indefinitely in a Bluetooth-enabled environment.
  • FIG. 1 is a schematic flowchart of a method for broadcasting data through Bluetooth according to an embodiment of the present invention
  • FIG. 2 is a schematic structural diagram of a Bluetooth device according to an embodiment of the present invention
  • 3 is a schematic diagram of a protocol and an entity used by a Bluetooth device according to an embodiment of the present invention
  • FIG. 4 is a schematic diagram of data exchange of a Bluetooth SDP according to an embodiment of the present invention
  • FIG. 5 is an exchange example of a Bluetooth SDP PDU according to an embodiment of the present invention.
  • FIG. 6 is a general working flow chart of a data broadcasting method according to an embodiment of the present invention.
  • FIG. 7 is a structural diagram of a data interaction model in an embodiment of the present invention.
  • FIG. 8 is a schematic diagram of data broadcasting using a Bluetooth SDP according to an embodiment of the present invention.
  • the invention is based on the Bluetooth SDP, and proposes a new method for exchanging data without connection and extending the Bluetooth transmission distance for data broadcasting, so that a piece of information can be quickly broadcasted through the Bluetooth SDP without connection, and further,
  • the invention can also expand the application range of the Bluetooth, so that the data transmission is not limited by the Bluetooth transmission distance.
  • the method for broadcasting data through Bluetooth involves implementing connectionless data transmission using a Bluetooth SDP and forming a connectionless transmission network using a Bluetooth device.
  • a Bluetooth device can act as both an SDP server and an SDP client.
  • a list of service records provided by the SDP server describing all the services provided by the server. Each service record contains all the information of this service.
  • the SDP client can obtain the service record of the SDP server by sending an SDP request.
  • a method for broadcasting data through Bluetooth is applied to a wireless transmission network including multiple Bluetooth devices, and the method includes the following steps:
  • Step 11 The first Bluetooth device obtains data to be broadcast.
  • the data to be broadcast may be data generated by the first device itself, and may also be data received by the user input to the device. Further, the data to be broadcast may also be data received from other Bluetooth devices (described below).
  • Step 12 The first Bluetooth device writes the data to be broadcast to the preset service record of the SDP server of the device, where the preset service record corresponds to the preset service.
  • the data to be broadcast is written to the service record of the Bluetooth SDP server, and the preset service record is a service record corresponding to the preset service; the preset service record includes an attribute list, and the to-be-broadcast data is written in the attribute.
  • the attribute value of the list That is to say, the data to be broadcast can be written as the attribute value of an attribute to the attribute list of the preset service record.
  • Using the Bluetooth name field can also achieve the same effect as using SDP, but the amount of data transferred will be less.
  • Step 13 The first Bluetooth device sends the preset service record to the second Bluetooth device according to the SDP request of the second Bluetooth device for the preset service, where the second Bluetooth device obtains the to-be-broadcast carried therein Data, thereby making connectionless data transfer between two Bluetooth devices.
  • the second Bluetooth device is any device that can perform Bluetooth communication with the first Bluetooth device. After scanning the first Bluetooth device, the second Bluetooth device may send an SDP request to obtain a preset service record (the preset service record corresponds to a certain preset service); the first Bluetooth device sends the second Bluetooth device based on the request. The corresponding service record is returned, so that the second device can extract the data to be broadcasted from the service record, and realize the transmission of data between the two Bluetooth devices.
  • the foregoing step 13 may include:
  • Step 131 The first Bluetooth device receives an SDP service query request for the preset service sent by the second Bluetooth device.
  • Step 132 The first Bluetooth device returns a handle of the preset service to the second Bluetooth device according to the received SDP service query request.
  • Step 133 The first Bluetooth device receives an SDP service attribute request sent by the second Bluetooth device, where the SDP service attribute request carries a handle of the preset service.
  • Step 134 The first Bluetooth device sends, to the second Bluetooth device, a preset service record corresponding to the preset service, according to the handle of the preset service, for the second Bluetooth device to use the preset service.
  • the to-be-broadcast data is obtained in the recorded attribute list.
  • the data to be broadcasted can be transmitted to multiple Bluetooth devices in the periphery through the above method in this embodiment, and then stepwise between adjacent Bluetooth devices. Transmission, so that the data can be quickly broadcasted, and the data broadcast transmission between the Bluetooth devices is realized.
  • Bluetooth technology has been widely used in related technologies, Bluetooth application scenarios are The distance between the devices has a high requirement, usually below 10 meters (of course, this distance may change with the development of Bluetooth), which obviously limits the communication between devices using Bluetooth technology to some extent.
  • the application distance of the Bluetooth communication can be expanded, and the limitation of the traditional Bluetooth transmission distance is exceeded.
  • the first Bluetooth device obtains data to be broadcast, which may specifically include the following steps:
  • Step 111 The first Bluetooth device sends an SDP service query request for the preset service to the third Bluetooth device.
  • Step 112 The first Bluetooth device receives a handle of the preset service returned by the third Bluetooth device for the received SDP service query request.
  • Step 113 The first Bluetooth device sends the preset to the third Bluetooth device. SDP service attribute request for the handle of the service;
  • Step 114 The first Bluetooth device receives a preset service record returned by the third Bluetooth device for the received SDP service attribute request, and extracts the to-be-broadcast data from the attribute list of the service record.
  • the above example only uses three devices as an example for description. Obviously, when there are more Bluetooth devices in the vicinity, the embodiment can realize data transmission from one Bluetooth device to surrounding Bluetooth devices, and then to the next Bluetooth device. Finally, the broadcast processing of the data is realized.
  • the embodiment of the present invention does not need to be between the Bluetooth devices (such as between the first and second Bluetooth devices, first, because the SDP request message and the response processing thereof are involved.
  • the third Bluetooth device establishes a connection, that is, the broadcast transmission processing of the data can be realized, thereby speeding up the data transmission diffusion process.
  • each Bluetooth device in the network in this embodiment needs to periodically perform Bluetooth search.
  • the specific search interval can be set according to the processing capability of the device and the delay of data transmission.
  • the embodiment of the present invention may further avoid the above problem by the following manner.
  • the Bluetooth device list that the data to be broadcast passes through is further maintained in the preset service record, that is, The own device ID is added to the list. That is to say, when the data to be broadcast passes through any Bluetooth device, the information of the device is added to the list. Specifically, when the data to be broadcast is generated by the first Bluetooth device itself or generated according to data input by the user, the first Bluetooth device will create a blank Bluetooth device list for the data to be broadcast, and then add itself to the list. Equipment Identity.
  • the device identifier can be compressed using a Bloom Filter or other similar compression method; and the data to be broadcast is the default service record of the first Bluetooth device from other Bluetooth devices.
  • the first Bluetooth device further extracts the corresponding Bluetooth device list from the preset service records of the other Bluetooth devices while obtaining the data to be broadcasted, and then adds the own device identifier in the list.
  • the first Bluetooth device further determines whether the second Bluetooth device exists in the Bluetooth device list corresponding to the to-be-broadcast data when receiving the SDP service query request for the preset service sent by the second Bluetooth device:
  • a rejection response may be returned to the second Bluetooth device, or no information may be returned to the second Bluetooth device.
  • step 132 134 the processing of the above step 132 134 is performed.
  • the foregoing method of the embodiment of the present invention can transmit data between Bluetooth devices without establishing a connection without artificially participating in the data broadcast process.
  • the embodiment of the present invention can also break the limitation of the Bluetooth transmission distance. Infinitely broadcast information in a Bluetooth-enabled environment.
  • the embodiment of the present invention further provides a Bluetooth device.
  • the Bluetooth device includes an SDP server 201 and an SDP client 202, and further includes:
  • the data obtaining unit 203 is configured to: obtain data to be broadcasted;
  • the recording unit 204 is configured to: write the data to be broadcast obtained by the data obtaining unit 203 into a preset service record of the SDP server, where the preset service record corresponds to a preset service;
  • the SDP server end 201 is configured to: send the preset service record to the another Bluetooth device according to an SDP request of another Bluetooth device for the preset service, where the another Bluetooth device obtains The data to be broadcast carried.
  • the preset service record includes an attribute list, and the to-be-broadcast data is written in an attribute value of the attribute list.
  • the SDP server is specifically configured to:
  • the recording unit may be further configured to: when the data to be broadcast is written to the preset service record of the SDP server of the device, maintain the compressed by the Bloom Filter in the preset service record. A list of Bluetooth devices through which the broadcast data passes.
  • the SDP server after receiving the SDP service query request for the preset service sent by the second Bluetooth device, further determines whether the second Bluetooth device exists in the Bluetooth device list, and if yes, rejects the SDP service query request; if not, returning a handle of the preset service to the second Bluetooth device.
  • the data obtaining unit 203 may be further configured to receive data to be broadcast input by a user.
  • the SDP client 203 is configured to: send an SDP service query request for the preset service to another Bluetooth device; and receive the another Bluetooth device for the received SDP service query request. Returning a handle of the preset service; sending an SDP service attribute request carrying a handle of the preset service to the further Bluetooth device; receiving the return of the further Bluetooth device for the received SDP service attribute request.
  • the preset service record and extracts the to-be-broadcast data from the attribute list of the service record.
  • the data obtaining unit is further used The data to be broadcasted is obtained from the SDP client.
  • Figure 3 shows the protocols and entities involved in the Bluetooth device.
  • the baseband is located at the bottom of the Bluetooth protocol stack and is responsible for frequency hopping and Bluetooth data packet transmission and verification.
  • Link Management Protocol (LMP) and L2CAP are the first and second layers of the Bluetooth protocol OSI.
  • LMP is responsible for the establishment and setup of connectivity between Bluetooth devices.
  • L2CAP mainly performs data disassembly and assembly, quality of service control, protocol multiplexing, group splitting and reassembly, and group extraction.
  • SDP is the Bluetooth service discovery protocol.
  • the server-side SDP maintains a service record database in which data broadcast service records are recorded.
  • the client uses the SDP to query whether the server supports the data broadcast service. If the server supports the data broadcast service, it returns the attribute list of the service.
  • RFCOMM is the Bluetooth adaptation layer, through which both devices connect and provide data transmission services for the upper layer.
  • the interactive control layer is used to discover broadcast services and control of data exchanged between devices. SDP and interactive control are used to implement data broadcast service discovery and execution data broadcast protocols, respectively, which is the core protocol layer of the profile.
  • the Bluetooth SDP is used to transmit and broadcast data without connection. Since the amount of data transmitted by the SDP is small, the generated broadcast data should be a small amount of data. In fact, there are many application scenarios that generate a small amount of data and need to be broadcasted, such as an unexpected event in industrial control, a distress signal that a mobile phone user suddenly falls, or a bus driver who prompts a thief on a bus, etc. .
  • a list of service records provided by the SDP server which describes all the services provided by the server. Each of these service records contains all the information about this service. All information about a service is contained in a service record that consists of a series of service attributes. Each service attribute describes a property of the service (eg: name, type, parameter, protocol used), consisting of the corresponding attribute ID and its corresponding value. The length of the attribute value is variable.
  • a general attribute value can be represented by any type of data element, and the embodiment of the present invention utilizes this attribute value to convey information.
  • FIG. 7 is a structural diagram of a model according to an embodiment of the present invention.
  • the embodiment of the present invention adds a corresponding broadcast service record, so that the Bluetooth client running the same program can The service is identified, and the Bluetooth device that is not running the program does not recognize the service.
  • each Bluetooth development and debugging platform will provide a corresponding operation interface.
  • FIG. 4 is a schematic diagram of SDP data exchange between two Bluetooth devices in the present invention.
  • the Bluetooth device A puts the data to be broadcast into the SDP server as a service record, and the Bluetooth B obtains the data to be broadcast by requesting the service record of the Bluetooth device A, and simultaneously
  • the Bluetooth device B also writes its own data to be broadcast or feedback information for the Bluetooth device B to its SDP server, and the Bluetooth device A also obtains corresponding data by request.
  • the performance in Figure 7 is the interaction between the client and the server SDP. Each device is both a client and a server.
  • FIG 5 is an example of SDP PDU (Protocol Data Unit) exchange.
  • the local Bluetooth device first sends an SDP-Service-SearchReq PDU, which contains the required service query mode X, which is by itself.
  • the UUID is used to identify it, which is represented in Figure 3 as Profile_X-UUID.
  • the SDP server returns a 32-bit handle to the one or more service records containing the "Profile-X-UUID" UUID, which is represented in Figure 5 as 32-bit Hndl:Hp.
  • the local Bluetooth device sends an SDP—serviceAttribute—Req PDU, which contains the service handle just received and one or more service attribute IDs that you want to query.
  • the returned SDP_Service_Search_Rsp PDU will contain an empty Service_Record-Handle-List, and Set the Total_Service_Recorat-Count parameter to the minimum value. If the service attribute to be queried does not exist on the SDP server side, the returned SDP_service_Attribute_Rsp PDU will contain an empty Attribute_List and the Attribute_List_Byte_Count parameter will be set to the minimum value. This indicates that the Bluetooth device does not support data broadcasting.
  • Figure 6 is a flow chart corresponding to the above text description, through which we can clearly see its workflow.
  • Figure 8 is an image of the broadcast data.
  • Bluetooth device 0 When Bluetooth device 0 has information to broadcast, it writes data to its SDP server, and then exchanges information with other Bluetooth devices within 10m around it through SDP (the specific process is shown in Figure 4), 4 ⁇ is set at 10m away from it.
  • Bluetooth device 1 When the Bluetooth device 1 receives the information to be transmitted by the Bluetooth device 0, it will repeat the process of the Bluetooth device 0, and then pass the information to the Bluetooth device within 10m of its surroundings, thus spreading step by step, and finally the Bluetooth device 0
  • the message to be broadcast is delivered to a wider range.
  • the Bluetooth device 2, the Bluetooth device 3, and the Bluetooth device 4 operate in the same manner as the Bluetooth device 1.
  • the embodiment of the present invention can break through the limitation of the Bluetooth transmission distance.
  • a new way of broadcasting information is provided.
  • the 10m mentioned above is the transmission distance of Bluetooth 3.0 and 3.0, and the Bluetooth 4.0 version can reach the transmission distance of 100m. With the development of Bluetooth, this distance will change constantly.
  • the modules may be implemented in software for execution by various types of processors.
  • an identified executable code module can comprise one or more physical or logical blocks of computer instructions, which can be constructed, for example, as an object, procedure, or function. Nonetheless, the executable code of the identified modules need not be physically located together, but may include different instructions stored in different physicalities. When these instructions are logically combined, they form a module and implement the specified purpose of the module. .
  • the executable code module can be a single instruction or a number of instructions, and can even be distributed over multiple different code segments, distributed among different programs, and distributed across multiple memory devices.
  • operational data can be identified within the module and can be implemented in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed at different locations (including on different storage devices), and may at least partially exist as an electronic signal on a system or network.
  • the module can be implemented in software, taking into account the level of the relevant hardware process, it can be Software-implemented modules, without considering the cost, those skilled in the art can construct corresponding hardware circuits to implement corresponding functions, and the hardware circuits include conventional ultra-large-scale integration.
  • VLSI voltage-sensitive integrated circuits
  • gate arrays and related semiconductors such as logic chips, transistors or other discrete components.
  • Modules can also be implemented with programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, and the like.
  • the method for broadcasting data through Bluetooth and the Bluetooth device provided by the above technical solution can transmit data between Bluetooth devices without establishing a connection; and, can also break the limitation of the Bluetooth transmission distance, and the information is in a Bluetooth environment. Unlimited broadcasts. Therefore, the present invention has strong industrial applicability.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

一种通过蓝牙广播数据的方法及蓝牙设备。其中所述方法包括:第一蓝牙设备获得待广播数据;第一蓝牙设备将待广播数据写入至本设备的蓝牙服务发现协议SDP服务器端的预设服务记录中,所述预设服务记录对应于预设服务;根据第二蓝牙设备针对所述预设服务的SDP请求,第一蓝牙设备将所述预设服务记录发送至第二蓝牙设备,以供所述第二蓝牙设备获得其中携带的待广播数据。上述技术方案可以在不建立连接的情况下在蓝牙设备之间传输数据,并且本发明还可以突破蓝牙传输距离的限制,在有蓝牙的环境中将信息无限的广播出去。

Description

一种通过蓝牙广播数据的方法及蓝牙设备
技术领域
本发明涉及蓝牙通信技术领域, 具体涉及一种通过蓝牙广播数据的方法 及蓝牙设备。
背景技术
蓝牙技术作为一种短距离无线连接技术, 正日益获得广泛的应用, 也越 来越受到人们的重视。 不管是在工业控制还是移动终端领域, 都能看到蓝牙 的应用。
蓝牙服务发现协议( SDP, Service Discovery Protocol )基于客户 /服务器 结构, 能让两个蓝牙设备相识并建立连接。 SDP的基本功能包括: 为客户提 供由服务属性搜索服务的功能; 提供由服务类发现服务的功能; 提供服务浏 览功能; 提供设备有效或服务有效的判决机制; 提供设备失效或服务失效的 判决机制; 提供唯一识别服务、 服务类和服务属性的功能; 不经第三方发现 另一个设备上的服务; 能够用于简单的设备; 提供增量获取服务信息机制; 支持服务发现信息的高速緩存,提高发现进程的效率或速度;能够独立传输; 能够用逻辑链路控制和适配协议( L2CAP, Logical Link Control and Adaptation Protocol )作为传输层协议; 能够发现和使用接入其他服务发现协议的服务; 无需主设备许可, 支持新服务的创建和定义。
发明内容
本发明实施例的目的是提供一种通过蓝牙广播数据的方法及蓝牙设备, 能够实现基于蓝牙的数据广播传输。
为解决上述技术问题, 釆用如下技术方案:
一种通过蓝牙广播数据的方法, 应用于包括多个蓝牙设备的无线传输网 络, 所述方法包括:
第一蓝牙设备获得待广播数据; 第一蓝牙设备将待广播数据写入至本设备的蓝牙服务发现协议 SDP服 务器端的预设服务记录中, 所述预设服务记录对应于预设服务;
根据第二蓝牙设备针对所述预设服务的 SDP请求,第一蓝牙设备将所述 预设服务记录发送至第二蓝牙设备, 以供所述第二蓝牙设备获得其中携带的 待广播数据。
可选地, 所述预设服务记录包括有属性列表, 所述待广播数据写入在所 述属性列表的属性值中;
第一蓝牙设备将所述预设服务记录发送至第二蓝牙设备的步骤包括: 第一蓝牙设备接收第二蓝牙设备发送的针对预设服务的 SDP服务查询 请求;
第一蓝牙设备根据接收到的 SDP服务查询请求,向第二蓝牙设备返回所 述预设服务的句柄;
第一蓝牙设备接收第二蓝牙设备发送的 SDP服务属性请求, 所述 SDP 服务属性请求携带有所述预设服务的句柄;
第一蓝牙设备根据所述预设服务的句柄, 向所述第二蓝牙设备发送所述 预设服务对应的预设服务记录, 以供所述第二蓝牙设备从所述预设服务记录 的属性列表中获得所述待广播数据。
可选地, 该方法还包括:
第一蓝牙设备在将待广播数据写入至本设备的 SDP服务器端的预设服 务记录时, 进一步在该预设服务记录中维护待广播数据所经过的蓝牙设备列 表;
第一蓝牙设备在接收第二蓝牙设备发送的针对预设服务的 SDP服务查 询请求后, 进一步判断第二蓝牙设备是否存在于所述蓝牙设备列表中, 若存 在, 则拒绝所述 SDP服务查询请求; 若不存在, 则向第二蓝牙设备返回所述 预设服务的句柄。
可选地, 所述第一蓝牙设备获得待广播数据包括: 所述第一蓝牙设备接 收用户输入的待广播数据。
可选地, 所述第一蓝牙设备获得待广播的数据的步骤包括: 第一蓝牙设备向第三蓝牙设备发送针对所述预设服务的 SDP服务查询 请求;
第一蓝牙设备接收第三蓝牙设备针对接收到的 SDP服务查询请求所返 回的所述预设服务的句柄;
第一蓝牙设备向第三蓝牙设备发送携带有所述预设服务的句柄的 SDP 服务属性请求;
第一蓝牙设备接收第三蓝牙设备针对接收到的 SDP服务属性请求所返 回的预设服务记录, 并从该服务记录的属性列表中提取出所述待广播数据。
一种蓝牙设备, 包括蓝牙服务发现协议 SDP服务器端和 SDP客户端, 还包括数据获得单元和记录单元, 其中:
所述数据获得单元设置成: 获得待广播数据;
所述记录单元设置成: 将所述数据获得单元获得的待广播数据写入至 SDP服务器端的预设服务记录中, 所述预设服务记录对应于预设服务;
所述 SDP服务器端设置成:根据另一蓝牙设备针对所述预设服务的 SDP 请求, 将所述预设服务记录发送至所述另一蓝牙设备, 以供所述另一蓝牙设 备获得其中携带的待广播数据。
可选地, 所述预设服务记录包括有属性列表, 所述待广播数据写入在所 述属性列表的属性值中;
所述 SDP服务器端设置成按照如下方式根据另一蓝牙设备针对所述预 设服务的 SDP请求, 将所述预设服务记录发送至所述另一蓝牙设备:
接收所述另一蓝牙设备发送的针对预设服务的 SDP服务查询请求; 根据接收到的 SDP服务查询请求,向所述另一蓝牙设备返回所述预设服 务的句柄;
接收所述另一蓝牙设备发送的 SDP服务属性请求, 所述 SDP服务属性 请求携带有所述预设服务的句柄;
根据所述预设服务的句柄, 向所述另一蓝牙设备发送所述预设服务对应 的预设服务记录, 以供所述另一蓝牙设备从所述预设服务记录的属性列表中 获得所述待广播数据。
可选地, 所述记录单元还设置成: 在将待广播数据写入至本设备的 SDP 服务器端的预设服务记录时, 在该预设服务记录中维护待广播数据所经过的 蓝牙设备列表;
所述 SDP服务器端还设置成:在接收第二蓝牙设备发送的针对预设服务 的 SDP服务查询请求后,判断第二蓝牙设备是否存在于所述蓝牙设备列表中, 若存在, 则拒绝所述 SDP服务查询请求; 若不存在, 则向第二蓝牙设备返回 所述预设服务的句柄。
可选地, 所述数据获得单元还设置成: 接收用户输入的待广播数据。 可选地, 所述 SDP客户端设置成:
向又一蓝牙设备发送针对所述预设服务的 SDP服务查询请求;
接收所述又一蓝牙设备针对接收到的 SDP服务查询请求所返回的所述 预设服务的句柄;
向所述又一蓝牙设备发送携带有所述预设服务的句柄的 SDP服务属性 请求;
接收所述又一蓝牙设备针对接收到的 SDP服务属性请求所返回的预设 服务记录, 并从该服务记录的属性列表中提取出所述待广播数据;
所述数据获得单元还设置成: 从所述 SDP客户端获得所述待广播数据。
从以上所述可以看出, 上述技术方案提供的通过蓝牙广播数据的方法及 蓝牙设备, 可以在不建立连接的情况下在蓝牙设备之间传输数据; 并且, 还 可以突破蓝牙传输距离的限制, 在有蓝牙的环境中将信息无限的广播出去。 附图概述
图 1为本发明实施例提供的一种通过蓝牙广播数据的方法的流程示意图; 图 2为本发明实施例提供的一种蓝牙设备的结构示意图; 图 3 为本发明实施例中蓝牙设备所用到的协议和实体示意图; 图 4为本发明实施例中蓝牙 SDP数据交换示意图;
图 5为本发明实施例中蓝牙 SDP PDU的一种交换示例;
图 6为本发明实施例所述数据广播方法的一般工作流程图;
图 7为本发明实施例中数据交互模型结构图;
图 8为本发明实施例中使用蓝牙 SDP进行数据广播的示意图。
本发明的较佳实施方式
本发明基于蓝牙 SDP, 提出了一种可以无连接交换数据并且能够扩展蓝 牙传输距离进行数据广播的新方法,使一条信息能够通过蓝牙 SDP在无连接 的情况下迅速的广播出去,更进一步的,本发明还可以扩大蓝牙的应用范围, 使得数据传输不受蓝牙传输距离的限制。 为使本发明的目的、 技术方案和优 点更加清楚, 下面将结合附图及具体实施例对本发明进行详细描述。
本发明实施例提出的通过蓝牙广播数据的方法,涉及到使用蓝牙 SDP实 现无连接数据传输以及使用蓝牙设备组成无连接传输网络。 一个蓝牙设备既 可以作为 SDP服务器端, 又可以作为 SDP客户端。 SDP服务器端提供的服 务记录列表, 描述了服务器提供的全部服务. 其中每条服务记录包含此项服 务的全部信息。 SDP客户端可以通过发送 SDP请求获取 SDP服务器端的服 务记录。 在本发明中正是利用蓝牙设备的以上特性来获取相邻设备的数据进 而达到广播数据的目的。
请参照图 1所示, 本发明实施例提供的通过蓝牙广播数据的方法, 应用 于包括多个蓝牙设备的无线传输网络, 该方法包括以下步骤:
步骤 11 , 第一蓝牙设备获得待广播数据。
这里, 待广播数据可以是第一设备自身产生的数据, 还可以是接收到的 用户向本设备输入的数据。 更进一步的, 待广播数据还可以是从其他蓝牙设 备处接收到的数据(将在下文中进行说明) 。
步骤 12, 第一蓝牙设备将待广播数据写入至本设备的 SDP服务器端的 预设服务记录中, 所述预设服务记录对应于预设服务。 这里, 将要广播的数据写入蓝牙 SDP服务器端的服务记录, 预设服务记 录是预设服务对应的服务记录; 所述预设服务记录包括有属性列表, 所述待 广播数据写入在所述属性列表的属性值中。 也就是说, 待广播数据可以作为 某个属性的属性值, 写入到预设服务记录的属性列表中。 使用蓝牙名字字段 也能实现跟使用 SDP—样的效果, 只是传输的数据量会少一些。
步骤 13 , 根据第二蓝牙设备针对所述预设服务的 SDP请求, 第一蓝牙 设备将所述预设服务记录发送至第二蓝牙设备, 以供所述第二蓝牙设备获得 其中携带的待广播数据, 从而在两个蓝牙设备之间进行无连接数据传输。
这里, 第二蓝牙设备是可以与第一蓝牙设备进行蓝牙通信的任意一台设 备。 第二蓝牙设备在扫描到第一蓝牙设备后, 可以发送 SDP请求以获得预设 服务记录(该预设服务记录对应于某个预设服务) ; 第一蓝牙设备基于该请 求向第二蓝牙设备返回对应的服务记录, 从而第二设备即可以从该服务记录 中提取到待广播数据, 实现了数据在两个蓝牙设备之间的传输。 具体, 上述 步骤 13可以包括:
步骤 131 , 第一蓝牙设备接收第二蓝牙设备发送的针对预设服务的 SDP 服务查询请求;
步骤 132, 第一蓝牙设备根据接收到的 SDP服务查询请求, 向第二蓝牙 设备返回所述预设服务的句柄;
步骤 133 , 第一蓝牙设备接收第二蓝牙设备发送的 SDP服务属性请求, 所述 SDP服务属性请求携带有所述预设服务的句柄;
步骤 134 , 第一蓝牙设备根据所述预设服务的句柄, 向所述第二蓝牙设 备发送所述预设服务对应的预设服务记录, 以供所述第二蓝牙设备从所述预 设服务记录的属性列表中获得所述待广播数据。
可以看出, 在网络中还存在更多的其他蓝牙设备时, 可以通过本实施例 的以上方法, 将待广播数据传输到周边的多个蓝牙设备, 进而在相邻蓝牙设 备之间的逐级传输, 从而可以将数据快速地广播出去, 实现了蓝牙设备之间 的数据广播传输。
虽然相关技术中蓝牙技术已经得到广泛应用, 但是蓝牙的应用场景对设 备之间的距离有着较高的要求, 通常在 10米以下(当然, 这个距离随着蓝牙 的发展可能变化) , 显然这在一定程度上限制了设备之间釆用蓝牙技术进行 通信。 应用本发明实施例所述方法, 可以扩大蓝牙通信的应用距离, 突破传 统蓝牙传输距离的限制。
例如,在上述步骤 11中, 当第一蓝牙设备所获得的待广播数据是从第三 蓝牙设备处获得的时,通过上述方法, 可以实现数据从第三蓝牙设备 ->第一 蓝牙设备 ->第二蓝牙设备的逐级传输,从而可以突破传统的蓝牙传输距离的 限制, 扩大蓝牙技术的应用范围。 此时, 上述步骤 11中, 所述第一蓝牙设备 获得待广播的数据, 具体可以包括以下步骤:
步骤 111 , 第一蓝牙设备向第三蓝牙设备发送针对所述预设服务的 SDP 服务查询请求;
步骤 112 , 第一蓝牙设备接收第三蓝牙设备针对接收到的 SDP服务查询 请求所返回的所述预设服务的句柄; 步骤 113 , 第一蓝牙设备向第三蓝牙设备发送携带有所述预设服务的句 柄的 SDP服务属性请求;
步骤 114 , 第一蓝牙设备接收第三蓝牙设备针对接收到的 SDP服务属性 请求所返回的预设服务记录, 并从该服务记录的属性列表中提取出所述待广 播数据。
以上举例仅以 3个设备为例进行说明, 显然, 在周边有更多的蓝牙设备 时, 本实施例可以实现数据从一个蓝牙设备传输到周边各个蓝牙设备, 进而 传输至下一级蓝牙设备, 最终实现数据的广播处理。
需要说明的是, 以上数据传输过程中, 由于仅涉及 SDP请求消息及其应 答处理, 因此本发明实施例并不需要在蓝牙设备之间 (如第一、 第二蓝牙设 备之间, 第一、 第三蓝牙设备之间)建立连接, 即可以实现数据的广播传输 处理, 从而可以加快数据传输扩散过程。 另外, 由于是使用蓝牙无连接进行 数据传输, 本实施例所述网络中的各个蓝牙设备需要定期进行蓝牙搜索, 具 体的搜索间隔可以根据设备处理能力以及对数据传输时延等要求进行设置。
考虑到第一蓝牙设备发送给第二蓝牙设备的数据, 有可能被包括第二蓝 牙设备在内的其他蓝牙设备再次发送给第一蓝牙设备, 从而可能引发广播风 暴的问题, 本发明实施例可以进一步通过以下方式来避免上述问题。
在上述步骤 12 中, 第一蓝牙设备在将待广播数据写入至本设备的 SDP 服务器端的预设服务记录时, 进一步在该预设服务记录中维护待广播数据所 经过的蓝牙设备列表, 即将自身设备标识增加在该列表中。 也就是说, 待广 播数据经过任何一个蓝牙设备时,该列表中都会增加该设备的信息。具体的, 在待广播数据是由第一蓝牙设备自己产生或根据用户输入的数据所产生时, 第一蓝牙设备将为该待广播数据新建一个空白的蓝牙设备列表, 然后在该列 表中增加自身设备标识。 因为传输数据字节数的限制, 该设备标识可以使用 布隆过滤器(Bloom Filter )或其它类似压缩方法进行压缩处理; 而在待广播 数据是第一蓝牙设备从其他蓝牙设备的预设服务记录中获得时, 第一蓝牙设 备在获得该待广播数据的同时, 进一步从其他蓝牙设备的预设服务记录中提 取对应的蓝牙设备列表, 然后在该列表中增加自身设备标识。
接着, 在上述步骤 131中, 第一蓝牙设备在接收第二蓝牙设备发送的针 对预设服务的 SDP服务查询请求时,进一步判断待广播数据对应的蓝牙设备 列表中是否存在该第二蓝牙设备:
若存在, 则拒绝所述 SDP服务查询请求, 具体的, 可以向第二蓝牙设备 返回一个拒绝响应, 或者不向第二蓝牙设备返回任何信息。
若不存在, 则执行上述步骤 132 134的处理。
综上, 本发明实施例的上述方法, 不需要人为参与数据广播过程, 就可 以在不建立连接的情况下在蓝牙设备之间传输数据; 并且, 本发明实施例还 可以突破蓝牙传输距离的限制, 在有蓝牙的环境中将信息无限的广播出去。
基于以上所述方法,本发明实施例还提供了一种蓝牙设备,如图 2所示, 该蓝牙设备包括 SDP服务器端 201和 SDP客户端 202 , 还包括:
数据获得单元 203设置成: 获得待广播数据;
记录单元 204设置成: 将所述数据获得单元 203获得的待广播数据写入 至 SDP服务器端的预设服务记录中, 所述预设服务记录对应于预设服务; 所述 SDP服务器端 201设置成:根据另一蓝牙设备针对所述预设服务的 SDP请求, 将所述预设服务记录发送至所述另一蓝牙设备, 以供所述另一蓝 牙设备获得其中携带的待广播数据。
其中, 所述预设服务记录包括有属性列表, 所述待广播数据写入在所述 属性列表的属性值中。 所述 SDP服务器端, 具体用于:
接收所述另一蓝牙设备发送的针对预设服务的 SDP服务查询请求; 根据接收到的 SDP服务查询请求,向所述另一蓝牙设备返回所述预设服 务的句柄;
接收所述另一蓝牙设备发送的 SDP服务属性请求, 所述 SDP服务属性 请求携带有所述预设服务的句柄;
根据所述预设服务的句柄, 向所述另一蓝牙设备发送所述预设服务对应 的预设服务记录, 以供所述另一蓝牙设备从所述预设服务记录的属性列表中 获得所述待广播数据。
为避免广播风暴, 所述记录单元, 还可以进一步用于在将待广播数据写 入至本设备的 SDP服务器端的预设服务记录时,在该预设服务记录中维护经 Bloom Filter压缩过的待广播数据所经过的蓝牙设备列表。 此时, 所述 SDP 服务器端,在接收第二蓝牙设备发送的针对预设服务的 SDP服务查询请求后, 进一步判断第二蓝牙设备是否存在于所述蓝牙设备列表中, 若存在, 则拒绝 所述 SDP服务查询请求; 若不存在, 则向第二蓝牙设备返回所述预设服务的 句柄。
作为一种实施方式, 所述数据获得单元 203 , 可以进一步用于接收用户 输入的待广播数据。
作为另一种实施方式, 所述 SDP客户端 203设置成: 向又一蓝牙设备发 送针对所述预设服务的 SDP服务查询请求;接收所述又一蓝牙设备针对接收 到的 SDP服务查询请求所返回的所述预设服务的句柄;向所述又一蓝牙设备 发送携带有所述预设服务的句柄的 SDP服务属性请求;接收所述又一蓝牙设 备针对接收到的 SDP服务属性请求所返回的预设服务记录,并从该服务记录 的属性列表中提取出所述待广播数据。 此时, 所述数据获得单元, 进一步用 于从所述 SDP客户端, 获得所述待广播数据。
为使上述内容更加容易理解,以下将进一步结合具体实现进行详细说明。 图 3为蓝牙设备所涉及到的协议和实体。 其中, 基带位于蓝牙协议栈的 最底层,负责跳频和蓝牙数据分组传输及校验等工作。链路管理协议( LMP ) 和 L2CAP是蓝牙协议 OSI 第一、 二层。 LMP 负责蓝牙各设备间连接的建 立和设置, L2CAP主要完成数据的拆装、 服务质量控制、 协议的复用、 分组 的分割和重组及组提取等功能。 SDP是蓝牙服务发现协议,服务器端的 SDP 维护一个服务记录数据库, 该数据库中记录了数据广播服务记录。 在设备双 方建立了 L2CAP之后,客户端利用 SDP 查询服务器端是否支持数据广播服 务, 如果服务器支持数据广播服务则返回该服务的属性列表。 RFCOMM是 蓝牙适配层, 设备双方通过该层连接并为上层提供数据传输服务。 交互控制 层用于发现广播服务以及设备之间交互数据的控制。 SDP和交互控制分别用 于实现数据广播服务发现和执行数据广播协议, 是该剖面的核心协议层。
下面对本发明实施例的应用过程进行阐述:
( 1 )产生将要广播的数据
本发明实施例使用蓝牙 SDP无连接传输并广播数据, 由于 SDP传输的 数据量较小, 因此产生的广播数据应该是少量的数据。 实际上, 产生少量数 据并需要广播的应用场景有很多, 比如在工业控制中出现了某个突发事件; 手机用户突然摔倒的求救信号或者公交车上公交车司机提示有小偷的信息等 等。
( 2 )将数据写入 SDP服务器的服务记录中
SDP服务器提供的服务记录列表, 它描述了服务器提供的全部服务. 其 中的每条服务记录包含此项服务的全部信息。 关于一个服务的所有信息都包 含在一个服务记录中, 该服务记录由一系列的服务属性组成。 每个服务属性 描述了服务的一个性质(比如: 名字, 类型, 参数, 使用的协议), 由相应的 属性 ID和其对应的值组成。 属性值的长度是可变的.一般的属性值可以用任 何类型的数据元表示, 本发明实施例也就是利用这个属性值来传递信息。 图 7 为本发明实施例的模型结构图。 在蓝牙服务器上的服务记录数据库中, 本 发明实施例添加相应的广播的服务记录, 使运行相同程序的蓝牙客户端能够 识别该服务, 而没有运行该程序的蓝牙设备不能识别该服务。 关于如何使用 相应接口操作 SDP服务记录数据库不是本发明的内容,每个蓝牙开发调试平 台都会提供相应的操作接口。
( 3 )使用蓝牙 SDP广播数据
图 4为本发明中两个蓝牙设备 SDP数据交换示意图, 蓝牙设备 A将要 广播的数据放到 SDP服务器中作为一条服务记录,蓝牙 B通过请求得到蓝牙 设备 A的服务记录获得要广播的数据,同时蓝牙设备 B将它自己要广播的数 据或者是给蓝牙设备 B的反馈信息也写入它的 SDP服务器, 蓝牙设备 A同 样通过请求获得相应的数据。表现在图 7中即为, 客户端和服务端 SDP的交 互, 每个设备既是客户端也是服务器端。
图 5为 SDP的 PDU (协议数据单元)交换示例, 由图所示可得, 本地蓝牙 设备先发出一个 SDP— Service— SearchReq PDU , 该 PDU 包含了所要求的服 务查询模式 X , 它是由自 己的 UUID 来标识的, 在图 3 中表示为 Profile— X—UUID。 在它的响应 PDU中, SDP服务器端返回查找到的一个或 多个包含有 "Profile— X—UUID" UUID 的服务记录的 32bit句柄, 图 5中表示 为 32-bit Hndl:Hp。 然后, 本地蓝牙设备发出一个 SDP— serviceAttribute— Req PDU, 它包含了刚刚收到的服务句柄和一个或多个想要查询的服务属性 ID, 在图 5 中只显示了 Protocol— Descriptor— List这一个属性, 它的属性 ID 是 0x00xx(xx分别代表十六进制数) 。 最后, SDP服务器端在它的响应 PDU 中 返回了查找到的相应的属性列表。从而得到其属性值,然后将该属性值写入服 务器端的服务记录数据库, 进而跟另外的设备进行交换, 从而很好地实现数 据的广播。
如果在一次服务查询中, SDP服务器端没有发现包含有所要求服务查询 模式的服务记录, 则在返回的 SDP— Service— Search— Rsp PDU 中将包含一个 空的 Service— Record— Handle— List, 并将 Total— Service— Record— Count参数设 置为最小值。 如果所要查询的服务属性在 SDP服务器端不存在, 则在返回的 SDP— service— Attribute— Rsp PDU 中将包含一个空的 Attribute— List,并将 Attribute— List— Byte— Count参数设置为最小值。此时表明该蓝牙设备不支持数 据广播。 图 6是与以上文字描述对应的流程图, 通过这个流程图我们可以清楚的 看到其工作流程. 图 8为广播数据的一个形象说明。 当蓝牙设备 0有信息需要广播时, 它 将数据写入其 SDP服务器中,然后跟其周围 10m内的其它蓝牙设备通过 SDP 交换信息 (具体过程如附图 4 ) , 4叚设在距其 10m的距离上分布有 4个蓝牙 设备 (蓝牙同时最大支持 7个设备), 分别为蓝牙设备 1、 蓝牙设备 2、 蓝牙设 备 3和蓝牙设备 4。 蓝牙设备 1在接收到蓝牙设备 0要传递的信息时, 它将 重复蓝牙设备 0的过程,又将该信息又传递给其周围 10m范围内的蓝牙设备, 这样逐级扩散, 最终将蓝牙设备 0要广播的消息传递到更广阔的范围内。 蓝 牙设备 2、 蓝牙设备 3以及蓝牙设备 4的工作方式跟蓝牙设备 1相同。 通过 这种方式, 本发明实施例可以突破蓝牙传输距离的限制。 为信息的广播提供 了一种新的方式。 以上所述的 10m是蓝牙 3.0及 3.0版本以下的传输距离, 蓝牙 4.0版本则最大可以达到 100m的传输距离, 随着蓝牙的发展, 这个距 离会不断变化。
此说明书中所描述的许多功能部件都被称为模块, 以便更加特别地强调 其实现方式的独立性。
本发明实施例中,模块可以用软件实现,以便由各种类型的处理器执行。 举例来说, 一个标识的可执行代码模块可以包括计算机指令的一个或多个物 理或者逻辑块, 举例来说, 其可以被构建为对象、 过程或函数。 尽管如此, 所标识模块的可执行代码无需物理地位于一起, 而是可以包括存储在不同物 理上的不同的指令, 当这些指令逻辑上结合在一起时, 其构成模块并且实现 该模块的规定目的。
实际上, 可执行代码模块可以是单条指令或者是许多条指令, 并且甚至 可以分布在多个不同的代码段上, 分布在不同程序当中, 以及跨越多个存储 器设备分布。 同样地, 操作数据可以在模块内被识别, 并且可以依照任何适 当的形式实现并且被组织在任何适当类型的数据结构内。 所述操作数据可以 作为单个数据集被收集, 或者可以分布在不同位置上(包括在不同存储设备 上) , 并且至少部分地可以仅作为电子信号存在于系统或网络上。
在模块可以利用软件实现时, 考虑到相关硬件工艺的水平, 所以可以以 软件实现的模块, 在不考虑成本的情况下, 本领域技术人员都可以搭建对应 的硬件电路来实现对应的功能, 所述硬件电路包括常规的超大规模集成
( VLSI )电路或者门阵列以及诸如逻辑芯片、 晶体管之类的相关半导体或者 是其它分立的元件。模块还可以用可编程硬件设备,诸如现场可编程门阵列、 可编程阵列逻辑、 可编程逻辑设备等实现。 以上所述仅是本发明的实施方式, 应当指出, 对于本技术领域的普通技 术人员来说, 在不脱离本发明原理的前提下, 还可以作出若干改进和润饰, 这些改进和润饰也应视为本发明的保护范围。
工业实用性
上述技术方案提供的通过蓝牙广播数据的方法及蓝牙设备, 可以在不建 立连接的情况下在蓝牙设备之间传输数据; 并且, 还可以突破蓝牙传输距离 的限制, 在有蓝牙的环境中将信息无限的广播出去。 因此本发明具有很强的 工业实用性。

Claims

权利要求书
1. 一种通过蓝牙广播数据的方法,应用于包括多个蓝牙设备的无线传输 网络, 所述方法包括:
第一蓝牙设备获得待广播数据;
第一蓝牙设备将待广播数据写入至本设备的蓝牙服务发现协议 SDP服 务器端的预设服务记录中, 所述预设服务记录对应于预设服务;
根据第二蓝牙设备针对所述预设服务的 SDP请求,第一蓝牙设备将所述 预设服务记录发送至第二蓝牙设备, 以供所述第二蓝牙设备获得其中携带的 待广播数据。
2. 如权利要求 1所述的方法,其中,所述预设服务记录包括有属性列表, 所述待广播数据写入在所述属性列表的属性值中;
第一蓝牙设备将所述预设服务记录发送至第二蓝牙设备的步骤包括: 第一蓝牙设备接收第二蓝牙设备发送的针对预设服务的 SDP服务查询 请求;
第一蓝牙设备根据接收到的 SDP服务查询请求,向第二蓝牙设备返回所 述预设服务的句柄;
第一蓝牙设备接收第二蓝牙设备发送的 SDP服务属性请求, 所述 SDP 服务属性请求携带有所述预设服务的句柄;
第一蓝牙设备根据所述预设服务的句柄, 向所述第二蓝牙设备发送所述 预设服务对应的预设服务记录, 以供所述第二蓝牙设备从所述预设服务记录 的属性列表中获得所述待广播数据。
3. 如权利要求 2所述的方法, 该方法还包括:
第一蓝牙设备在将待广播数据写入至本设备的 SDP服务器端的预设服 务记录时, 进一步在该预设服务记录中维护待广播数据所经过的蓝牙设备列 表;
第一蓝牙设备在接收第二蓝牙设备发送的针对预设服务的 SDP服务查 询请求后, 进一步判断第二蓝牙设备是否存在于所述蓝牙设备列表中, 若存 在, 则拒绝所述 SDP服务查询请求; 若不存在, 则向第二蓝牙设备返回所述 预设服务的句柄。
4. 如权利要求 1至 3任一项所述的方法, 其中, 所述第一蓝牙设备获得 待广播数据包括: 所述第一蓝牙设备接收用户输入的待广播数据。
5. 如权利要求 1至 3任一项所述的方法, 其中, 所述第一蓝牙设备获得 待广播的数据的步骤包括:
第一蓝牙设备向第三蓝牙设备发送针对所述预设服务的 SDP服务查询 请求;
第一蓝牙设备接收第三蓝牙设备针对接收到的 SDP服务查询请求所返 回的所述预设服务的句柄;
第一蓝牙设备向第三蓝牙设备发送携带有所述预设服务的句柄的 SDP 服务属性请求;
第一蓝牙设备接收第三蓝牙设备针对接收到的 SDP服务属性请求所返 回的预设服务记录, 并从该服务记录的属性列表中提取出所述待广播数据。
6. 一种蓝牙设备,包括蓝牙服务发现协议 SDP服务器端和 SDP客户端, 还包括数据获得单元和记录单元, 其中:
所述数据获得单元设置成: 获得待广播数据;
所述记录单元设置成: 将所述数据获得单元获得的待广播数据写入至 SDP服务器端的预设服务记录中, 所述预设服务记录对应于预设服务;
所述 SDP服务器端设置成:根据另一蓝牙设备针对所述预设服务的 SDP 请求, 将所述预设服务记录发送至所述另一蓝牙设备, 以供所述另一蓝牙设 备获得其中携带的待广播数据。
7. 如权利要求 6所述的蓝牙设备, 其中, 所述预设服务记录包括有属性 列表, 所述待广播数据写入在所述属性列表的属性值中;
所述 SDP服务器端设置成按照如下方式根据另一蓝牙设备针对所述预 设服务的 SDP请求, 将所述预设服务记录发送至所述另一蓝牙设备:
接收所述另一蓝牙设备发送的针对预设服务的 SDP服务查询请求; 根据接收到的 SDP服务查询请求,向所述另一蓝牙设备返回所述预设服 务的句柄;
接收所述另一蓝牙设备发送的 SDP服务属性请求, 所述 SDP服务属性 请求携带有所述预设服务的句柄;
根据所述预设服务的句柄, 向所述另一蓝牙设备发送所述预设服务对应 的预设服务记录, 以供所述另一蓝牙设备从所述预设服务记录的属性列表中 获得所述待广播数据。
8. 如权利要求 7所述的蓝牙设备, 其中,
所述记录单元还设置成:在将待广播数据写入至本设备的 SDP服务器端 的预设服务记录时, 在该预设服务记录中维护待广播数据所经过的蓝牙设备 列表;
所述 SDP服务器端还设置成:在接收第二蓝牙设备发送的针对预设服务 的 SDP服务查询请求后,判断第二蓝牙设备是否存在于所述蓝牙设备列表中, 若存在, 则拒绝所述 SDP服务查询请求; 若不存在, 则向第二蓝牙设备返回 所述预设服务的句柄。
9. 如权利要求 6至 8任一项所述的蓝牙设备, 其中, 所述数据获得单元 还设置成: 接收用户输入的待广播数据。
10. 如权利要求 6至 8任一项所述的蓝牙设备, 其中, 所述 SDP客户端 设置成:
向又一蓝牙设备发送针对所述预设服务的 SDP服务查询请求;
接收所述又一蓝牙设备针对接收到的 SDP服务查询请求所返回的所述 预设服务的句柄;
向所述又一蓝牙设备发送携带有所述预设服务的句柄的 SDP服务属性 请求;
接收所述又一蓝牙设备针对接收到的 SDP服务属性请求所返回的预设 服务记录, 并从该服务记录的属性列表中提取出所述待广播数据;
所述数据获得单元还设置成: 从所述 SDP客户端获得所述待广播数据。
PCT/CN2013/081217 2012-10-23 2013-08-09 一种通过蓝牙广播数据的方法及蓝牙设备 WO2014063514A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201210407397.7A CN103780285A (zh) 2012-10-23 2012-10-23 一种通过蓝牙广播数据的方法及蓝牙设备
CN201210407397.7 2012-10-23

Publications (1)

Publication Number Publication Date
WO2014063514A1 true WO2014063514A1 (zh) 2014-05-01

Family

ID=50543961

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2013/081217 WO2014063514A1 (zh) 2012-10-23 2013-08-09 一种通过蓝牙广播数据的方法及蓝牙设备

Country Status (2)

Country Link
CN (1) CN103780285A (zh)
WO (1) WO2014063514A1 (zh)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104218979A (zh) * 2014-07-31 2014-12-17 北京升哲科技有限公司 在非连接状态下获取传感数据的传感器、智能设备及方法
CN105581774A (zh) * 2014-10-22 2016-05-18 长天科技股份有限公司 遵循蓝牙低功耗通信协议的生理信息监测系统
CN104346838A (zh) * 2014-10-22 2015-02-11 深圳市金立通信设备有限公司 一种终端及系统
CN104392500A (zh) * 2014-10-22 2015-03-04 深圳市金立通信设备有限公司 一种考勤方法
CN105336013B (zh) * 2015-10-16 2018-10-09 江苏协信信息科技有限公司 一种通过信标广播实现点名的方法和系统
CN105430601B (zh) * 2015-11-18 2020-02-11 腾讯科技(深圳)有限公司 一种蓝牙设备列表的展现方法、装置及移动终端
CN105792106B (zh) * 2016-03-01 2019-03-22 北京明华联盟科技有限公司 一种蓝牙配对记录管理方法及装置
CN105867155A (zh) * 2016-05-11 2016-08-17 深圳易联智能电气有限公司 一种智能灯及其蓝牙控制方法、系统
CN106454706A (zh) * 2016-10-12 2017-02-22 广州视源电子科技股份有限公司 一种通知信息的推送方法及系统
CN107592607B (zh) * 2017-09-07 2021-07-02 飞天诚信科技股份有限公司 一种蓝牙复合设备及其通信方法
CN110300393B (zh) * 2018-03-23 2022-08-16 阿尔卑斯通信器件技术(上海)有限公司 蓝牙通信装置、蓝牙通信系统以及蓝牙通信方法
CN111263350A (zh) * 2018-11-30 2020-06-09 北京京东尚科信息技术有限公司 写卡设备、系统和方法
CN112073768B (zh) * 2019-06-10 2023-03-21 海信视像科技股份有限公司 蓝牙通信方法及显示设备
CN110691332A (zh) * 2019-09-17 2020-01-14 湖南简成信息技术有限公司 基于蓝牙广播的数据处理方法、设备及存储介质
CN113162997B (zh) * 2021-04-02 2022-04-12 深圳市网旭科技有限公司 数据传输方法、装置、电子设备及可读存储介质
CN114257579A (zh) * 2021-12-20 2022-03-29 支付宝(杭州)信息技术有限公司 一种信息传输的方法、装置、设备及介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1777321A (zh) * 2004-11-15 2006-05-24 华为技术有限公司 蓝牙接入点的链路管理方法
CN1913383A (zh) * 2005-07-20 2007-02-14 Lg电子株式会社 用于从短距离通信终端获得应用数据的设备和方法
CN101341686A (zh) * 2005-12-20 2009-01-07 微软公司 无线网络中近程服务的发现
US20100136910A1 (en) * 2008-12-03 2010-06-03 Electronics And Telecommunications Research Institute Apparatus and method for device search for high-speed based bluetooth applications

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080006253A (ko) * 2006-07-12 2008-01-16 삼성전자주식회사 전송 효율을 개선한 블루투스 마스터 및 이를 이용한데이터 전송 방법

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1777321A (zh) * 2004-11-15 2006-05-24 华为技术有限公司 蓝牙接入点的链路管理方法
CN1913383A (zh) * 2005-07-20 2007-02-14 Lg电子株式会社 用于从短距离通信终端获得应用数据的设备和方法
CN101341686A (zh) * 2005-12-20 2009-01-07 微软公司 无线网络中近程服务的发现
US20100136910A1 (en) * 2008-12-03 2010-06-03 Electronics And Telecommunications Research Institute Apparatus and method for device search for high-speed based bluetooth applications

Also Published As

Publication number Publication date
CN103780285A (zh) 2014-05-07

Similar Documents

Publication Publication Date Title
WO2014063514A1 (zh) 一种通过蓝牙广播数据的方法及蓝牙设备
US8023940B2 (en) Connecting ad hoc piconets to wide area networks and/or grid computing networks
US9794323B2 (en) Method and apparatus for performing object transfer service using bluetooth low energy in wireless communication system
US10932313B2 (en) Wireless connection switching method and terminal
CN108323246B (zh) 组网方法、芯片及无线网络系统
CN104717603B (zh) 一种蓝牙低功耗组网并支持便捷互联的方法及系统
CN117793952A (zh) 一种通信方法及装置
US11172530B2 (en) Communication establishment method and terminal
US20150264134A1 (en) Enhanced distributed resource directory
WO2016155286A1 (zh) 一种基于蓝牙的多设备智能互连方法及系统
CN104704906A (zh) 在无线保真直连(wfd)网络环境中建立wfd连接的方法和系统
US9781579B2 (en) Method and device for realizing terminal WIFI talkback
CN111786998A (zh) 基于微服务调用的权限管理方法、装置及存储介质
WO2022143071A1 (zh) 连接建立方法及电子设备
EP3447996A1 (en) Resource subscription method, resource subscription device, and resource subscription system
CN101656745A (zh) 实现文件共享的无线通信设备、系统及文件共享方法
WO2013166762A1 (zh) 个人网设备组网方法及系统
US10924904B2 (en) Method and apparatus for performing object transfer service by using bluetooth communication in wireless communication system
US10492060B2 (en) Method and device for transmitting/receiving data in wireless communication system
WO2013178119A1 (zh) 业务提供方法及系统、终端
Sedov et al. Time and energy efficient service discovery in Bluetooth
WO2022151420A1 (zh) 一种数据包传输的方法、装置和系统
CN105187097A (zh) 一种基于蓝牙的内外设备互联互通实现方法及系统
WO2023040590A1 (zh) 通道配置方法及装置
CN106411534A (zh) 一种具有接口识别和无线分享功能的嵌入式设备及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13848987

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13848987

Country of ref document: EP

Kind code of ref document: A1