KR20230097649A - Method for transmitting and receiving medical data using BLE and device supporting the same - Google Patents

Abstract

This specification provides a method for performing GHS services. More specifically, the method includes advertising, by a server, for a connectable GHS beacon; adding, by the client, a new device to the profile of the client; sending, by the client, a first pairing request to the server; connecting, by the server, a compatible GHS client to the client by confirming pairing with the client; reading, by the server, characteristics of the server to the client; setting, by the server, GHS settings; and sending, by the client, a GHS start to the server.

Description

Method for transmitting and receiving medical data using BLE and device supporting the same {Method for transmitting and receiving medical data using BLE and device supporting the same}

The present specification relates to a method for transmitting and receiving medical data, and more particularly, to a method for transmitting and receiving medical data using BLE technology and an apparatus supporting the same.

Bluetooth is one of the technologies underlying IoT, and is a short-distance wireless technology standard that exchanges information by connecting mobile devices such as mobile phones, laptops, earphones, and headsets. Bluetooth communicates using a frequency of 2400 to 2483.5 MHz, which is an Industrial, Scientific, and Medical (ISM) band. In this band, Bluetooth has a guard band of 2 MHz below and 3.5 MHz above, uses a total of 79 channels with a bandwidth of 1 MHz for each channel, and uses frequency hopping to prevent radio interference. Frequency hopping is also called frequency hopping, and is a method of transmitting data while rapidly moving a channel according to a specific pattern. The connection between Bluetooth devices consists of a master and a slave, and up to 7 slave devices can be connected to one master device. The master and slave are not fixed, and the master and slave may change depending on the situation.

Bluetooth communication methods include a BR/EDR (Basic Rate/Enhanced Data Rate) method and a low power method, LE (Low Energy) method. The BR/EDR scheme may be referred to as Bluetooth Classic. The Bluetooth Classic method includes a Bluetooth technology inherited from Bluetooth 1.0 using a basic rate and a Bluetooth technology using an enhanced data rate supported from Bluetooth 2.0.

Bluetooth Low Energy (Hereinafter referred to as Bluetooth LE) Applied from Bluetooth 4.0, it consumes less power and can stably provide hundreds of kilobytes (KB) of information. This Bluetooth low energy technology utilizes an attribute protocol to exchange information between devices. This Bluetooth LE scheme can reduce energy consumption by reducing header overhead and simplifying operations. Based on Bluetooth LE, Bluetooth Mesh supports many-to-many device communication and optimizes the creation of large device networks. It has industrial-level stability, scalability and security, and supports global interoperability. In particular, it is suitable for IoT solutions such as building automation, sensor networks, and asset tracking, where thousands of devices need to communicate with each other reliably and securely. The mesh network extends the range of Bluetooth Low Energy connectivity and can handle endless requests from tens of thousands of devices because it uses a technology called 'Managed Flood'. Bluetooth mesh networking contributes to expanding the use of Bluetooth beyond the consumer to factory automation systems, smart offices, and smart cities.

Bluetooth version 5 is an upgraded version of Bluetooth version 4. Theoretically, Bluetooth version 5 can connect up to 400m in an unobstructed environment. Bluetooth version 5 can connect up to 120 meters in a realistic configuration, four times that of Bluetooth version 4. The data transfer rate also doubles to 2 Mbps. Therefore, Bluetooth version 5 makes it easier to transmit the firmware of devices with faster speed, wider connection distance, and error correction function, and is useful for automobiles, intelligent meters, and medical devices implanted in the human body. In addition, in Bluetooth, pairing (connection) is basically made between two devices, and if a function called broadcast is used, it is possible to communicate with neighboring beacons in multiplex without separate pairing. Bluetooth version 5 increases this broadcast capacity by eight times, enabling a wider variety of beacon services.

Some Bluetooth devices do not have a display or user interface. The complexity of connection/management/control/disconnection (Connection/Management/Control/Disconnection) between various types of Bluetooth devices and, among other things, Bluetooth devices with similar technologies is increasing.

In addition, the Medical WG of the Bluetooth SIG standard group defines data formats and protocol operations for exchanging medical data with Bluetooth Low Energy (BLE) technology. However, as medical data that needs to be exchanged between devices diversifies, technology to cope with this is being discussed, and this is in progress as a standard document Generic Health Sensor Service/Profile (GHS). Unlike conventional smart bands and earphones, medical devices are more sensitive to security and authority management because they are used by various people and exchanged data includes user information. In addition, there is a need to efficiently design reconnection and connectivity management between devices because the user's frequency of using services and usage scenarios are different.

An object of the present specification is to provide a method for transmitting and receiving medical data between a collector and a sensor using BLE technology.

This specification provides a method for performing GHS services. More specifically, the method includes advertising, by a server, for a connectable GHS beacon; adding, by the client, a new device to the profile of the client; sending, by the client, a first pairing request to the server; connecting, by the server, a compatible GHS client to the client by confirming pairing with the client; reading, by the server, characteristics of the server to the client; setting, by the server, GHS settings; and sending, by the client, a GHS start to the server.

The present specification has an effect of safely and quickly transmitting and receiving medical data including biometric information between a collector and a sensor using BLE technology.

On the other hand, the effects obtainable in this specification are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the description below. You will be able to.

1 is a schematic diagram showing an example of a wireless communication system using Bluetooth low energy technology proposed in this specification.
Figure 2 shows an example of an internal block diagram of a server device and a client device that can implement the methods proposed in this specification.
3 shows an example of an architecture of Bluetooth Basic Rate (BR)/Enhanced Data Rate (EDR).
4 shows an example of an architecture of Bluetooth Low Energy (LE).
5 is a diagram showing an example of a GATT Profile structure of Bluetooth low energy.
6 is a flowchart illustrating an example of a connection procedure method in Bluetooth low energy technology.
7 is a flowchart illustrating an example of a method of providing an object transfer service in Bluetooth low energy technology.
8 is a flowchart illustrating an example of a connection procedure method in Bluetooth BR/EDR technology.
9 is a schematic diagram illustrating an example of a Bluetooth mesh network to which the present specification can be applied.
10 is a diagram illustrating an example of a protocol stack of a Bluetooth mesh network to which the present specification can be applied.
11 is a flowchart illustrating an example of a method for a device to which the present specification can be applied to participate in a Bluetooth mesh network.
12 shows an example of an arrival angle (AoA) and a departure angle (AoD) to which the method proposed in this specification can be applied.
13 is a diagram showing an example of a CTE field.
14 is a diagram illustrating an example of service discovery and attribute caching.
15 shows an example of using an advertising channel according to the Bluetooth Core Specification v5.0 with a fixed sequence of advertising channels.
16 is a diagram illustrating an example of using an advertising channel according to Bluetooth Core Specification v5.1 using a randomized channel index sequence.
17 is a diagram illustrating an example of using periodic advertisement synchronization transmission.
18 is a diagram showing an example of a conceptual diagram of a GHS service structure proposed in this specification.
19 is a conceptual diagram illustrating an example of the GHS service proposed in this specification.
20 is a conceptual diagram illustrating an example of a DIS proposed in this specification.
21 is a conceptual diagram illustrating an example of a general time service proposed in this specification.
22 is a conceptual diagram illustrating an example of the BAS proposed in this specification.
23 is a conceptual diagram illustrating an example of an RCS proposed in this specification.

The foregoing objects, features and advantages of this specification will become more apparent from the following detailed description taken in conjunction with the accompanying drawings. However, the present specification may apply various changes and may have various embodiments. Hereinafter, specific embodiments will be illustrated in the drawings and described in detail. Like reference numerals designate essentially like elements throughout the specification. In addition, if it is determined that a detailed description of a known function or configuration related to the present specification may unnecessarily obscure the gist of the present specification, the detailed description thereof will be omitted.

Hereinafter, the method and apparatus related to the present specification will be described in more detail with reference to the drawings. The suffixes "module" and "unit" for components used in the following description are given or used together in consideration of ease of writing the specification, and do not have meanings or roles that are distinct from each other by themselves.

1 is a schematic diagram showing an example of a wireless communication system using Bluetooth low energy technology proposed in this specification.

The wireless communication system 100 includes at least one server device (Server Device, 120) and at least one client device (Client Device, 110).

The server device and the client device perform Bluetooth communication using Bluetooth Low Energy (BLE, hereinafter referred to as 'BLE' for convenience) technology.

In BLE technology, (1) the number of RF channels is 40, (2) the data transmission rate supports 1Mbps, (3) the topology is a scatternet structure, (4) the latency is 3ms, and (5) the maximum current is less than 15mA, (6) the output power is less than 10mW (10dBm), and (7) is mainly used for applications such as mobile phones, watches, sports, healthcare, sensors, and device control.

The server device 120 may operate as a client device in relation to other devices, and the client device may operate as a server device in relation to other devices. That is, in the BLE communication system, any one device can operate as a server device or a client device, and if necessary, it is also possible to simultaneously operate as a server device and a client device.

The server device 120 includes a data service device, a slave device device, a slave, a server, a conductor, a host device, a gateway, and a sensing device. It can be expressed as a sensing device, a monitoring device, and the like.

The client device 110 includes a master device, a master device, a client, a member, a sensor device, a sink device, a collector, a third device, a fourth device, and the like. can be expressed

A server device (or server device) and a client device (or client device) correspond to the main components of the wireless communication system, and the wireless communication system may include other components in addition to the server device and the client device.

The server device refers to a device that receives data from a client device and directly communicates with the client device to provide data to the client device through a response when receiving a data request from the client device.

In addition, the server device sends a notification message and an indication message to the client device to provide data information to the client device. In addition, when the server device transmits the instruction message to the client device, it receives a confirmation message corresponding to the instruction message from the client.

In addition, the server device provides data information to the user through a display unit or receives a request input from the user through a user input interface in the process of transmitting and receiving notification, instruction, and confirmation messages with the client device. can do.

In addition, the server device may read data from a memory unit or write new data to the memory unit in the process of transmitting and receiving messages with the client device.

In addition, one server device can be connected to a plurality of client devices, and can be easily reconnected (or connected) with client devices by utilizing bonding information.

The client device 120 refers to a device that requests data information and data transmission from a server device.

The client device receives data from the server device through a notification message, an instruction message, and the like, and when receiving the instruction message from the server device, sends a confirmation message in response to the instruction message.

Similarly, the client device may provide information to a user through an output unit or receive an input from a user through an input unit in the process of transmitting and receiving messages with the server device.

In addition, the client device may read data from a memory or write new data to a corresponding memory while transmitting and receiving a message with the server device.

Hardware components such as an output unit, an input unit, and a memory of the server device and the client device will be described in detail with reference to FIG. 2 .

In addition, the wireless communication system may configure Personal Area Networking (PAN) through Bluetooth technology. For example, in the wireless communication system, files and documents can be exchanged quickly and safely by establishing a private piconet between devices.

2 shows an example of an internal block diagram of a server device and a client device capable of implementing the methods proposed in this specification.

A server device may be connected with at least one client device.

Also, if necessary, the internal block diagram of each device may further include other components (modules, blocks, units), and some of the components shown in FIG. 2 may be omitted.

As shown in FIG. 2, the server device includes a display unit 111, an input unit 112, a power supply unit 113, a processor 114, and a memory unit. , 115), a Bluetooth interface (Bluetooth Interface, 116), another communication interface (Other Interface, 117), and a communication unit (or transceiver, 118).

The output unit 111, the input unit 112, the power supply unit 113, the processor 114, the memory 115, the Bluetooth interface 116, the other communication interface 117, and the communication unit 118 are proposed herein. How to do is functionally linked to perform.

In addition, the client device includes an output unit (Display Unit, 121), an input unit (User Input Interface, 122), a power supply unit (Power Supply Unit, 123), a processor (Processor, 124), a memory (Memory Unit, 125), and a Bluetooth interface. (Bluetooth Interface, 126) and a communication unit (or transceiver, 127).

The output unit 121, the input unit 122, the power supply unit 123, the processor 124, the memory 125, the Bluetooth interface 126, and the communication unit 127 are configured to perform the method proposed in this specification. are functionally connected.

The Bluetooth interfaces 116 and 126 refer to units (or modules) capable of transmitting requests/responses, commands, notifications, instruction/confirmation messages, etc., or data between devices using Bluetooth technology.

The memories 115 and 125 are units implemented in various types of devices and refer to units in which various types of data are stored.

The processors 114 and 124 refer to modules that control the overall operation of a server device or a client device, and control to request transmission of messages through a Bluetooth interface and other communication interfaces, and to process received messages.

The processors 114 and 124 may be expressed as a controller, a control unit, or a controller.

The processors 114 and 124 may include application-specific integrated circuits (ASICs), other chipsets, logic circuits, and/or data processing devices.

The memories 115 and 125 may include read-only memory (ROM), random access memory (RAM), flash memory, memory cards, storage media, and/or other storage devices.

The communication units 118 and 127 may include baseband circuits for processing radio signals. When the embodiment is implemented as software, the above-described technique may be implemented as a module (process, function, etc.) that performs the above-described functions. A module can be stored in memory and executed by a processor.

The memories 115 and 125 may be internal or external to the processors 114 and 124 and may be connected to the processors 114 and 124 by various well-known means.

The output units 111 and 121 refer to modules for providing device status information and message exchange information to the user through a screen.

The power supply unit (power supply units 113 and 123) refers to a module that receives external power and internal power under the control of a control unit and supplies power required for operation of each component.

As seen above, the BLE technology has a small duty cycle and can greatly reduce power consumption through a low data rate, so that the power supply unit can provide the necessary power for the operation of each component even with a small output power (less than 10mW (10dBm)). power can be supplied.

The input units 112 and 122 refer to modules that allow the user to control the operation of the device by providing a user's input to the control unit, such as a screen button.

3 and 4 are diagrams illustrating an example of a Bluetooth communication architecture to which the methods proposed in this specification can be applied.

Specifically, FIG. 3 shows an example of a Bluetooth Basic Rate (BR)/Enhanced Data Rate (EDR) architecture.

4 shows an example of an architecture of Bluetooth Low Energy (LE).

First, as shown in FIG. 3, the Bluetooth BR/EDR architecture includes a controller stack (Controller stACK) 310, a Host Controller Interface (HCI) 320, and a host stack (Host stACK) 330.

The controller stack (or controller module 310) refers to a wireless transmission/reception module that receives a 2.4 GHz Bluetooth signal and hardware for transmitting or receiving Bluetooth packets, and includes a BR/EDR Radio layer 311 and a BR/EDR Baseband layer 312. ), and a BR/EDR Link Manager layer 313.

The BR/EDR Radio layer 311 is a layer that transmits and receives 2.4 GHz radio signals, and can transmit data by hopping 79 RF channels when Gaussian Frequency Shift Keying (GFSK) modulation is used.

The BR/EDR baseband layer 312 is responsible for transmitting a digital signal, selects a channel sequence hopping 1600 times per second, and transmits a 625us long time slot for each channel.

The Link Manager layer 313 utilizes LMP (Link Manager Protocol) to control overall operations (link setup, control, security) of Bluetooth Connection.

The Link Manager layer may perform the following functions.

- ACL/SCO logical transport and logical link setup and control.

- Detach: Aborts the connection and notifies the other device of the reason for the abort.

- Power control and role switch.

- Performs security (authentication, pairing, encryption) functions.

The Host Controller Interface layer 320 provides an interface between the host module 330 and the controller module 310 so that the host can provide commands and data to the controller, and the controller can provide events and data to the host. .

The host stack (or host module 330) includes L2CAP (337), SDP (Service Discovery Protocol, 333), BR/EDR Protocol (332), BR/EDR Profiles (331), Attribute Protocol (336), Generic Access Profile (GAP,334) and Generic Attribute Profile (GATT,335).

The Logical Link Control and Adaptation Protocol (L2CAP, 337) provides one bidirectional channel for transmitting data to a specific protocol or profile.

The L2CAP multiplexes various protocols and profiles provided by Bluetooth.

L2CAP of Bluetooth BR/EDR uses dynamic channel, supports protocol service multiplexer, retransmission, and streaming mode, and provides segmentation and reassembly, per-channel flow control, and error control.

The Service Discovery Protocol (SDP) 333 refers to a protocol for finding services (profiles and protocols) supported by a Bluetooth device.

The BR/EDR Protocol and Profiles 332 and 331 define a service (profile) using Bluetooth BR/EDR and an application protocol for exchanging these data.

The Attribute Protocol 336 is a Server-Client structure and defines rules for accessing data of a counterpart device. There are six message types (Request message, Response message, Command message, Notification message, and Indication message) as shown below.

- request message from client to server with response message from server to client

-Command message from client to server without response message

-Notification message from server to client without confirmation message

-Indication messages from the server to the client, along with confirmation messages from the client to the server

The Generic Attribute Profile (GATT, 335) defines the type of attribute.

The Generic Access Profile (GAP, 334) defines device discovery, connection, and methods of providing information to users, and provides privacy.

As shown in FIG. 4, the BLE architecture includes a controller stack (Controller stACK) operable to process a radio interface where timing is critical and a host stack (Host stACK) operable to process high level data.

The controller stACK may be called a controller, but in order to avoid confusion with the processor, which is an internal component of the device previously mentioned in FIG. 2, it will be expressed as a controller stACK below.

First, the controller stack may be implemented using a communication module that may include a Bluetooth radio and a processor module that may include a processing device such as, for example, a microprocessor.

The host stack may be implemented as part of the OS running on the processor module or as an instantiation of a package (pACKage) on the OS.

In some instances, a controller stack and a host stack may operate or run on the same processing device within a processor module.

The host stack includes GAP (Generic Access Profile, 410), GATT based Profiles (420), GATT (Generic Attribute Profile, 430), ATT (Attribute Protocol, 440), SM (Security Manage, 450), L2CAP (Logical Link Control and Adaptation Protocol, 460). However, the host stack is not limited thereto and may include various protocols and profiles.

The host stack uses L2CAP to multiplex various protocols and profiles provided by Bluetooth.

First, Logical Link Control and Adaptation Protocol (L2CAP) 460 provides one bi-directional channel for transmitting data to a specific protocol or profile.

L2CAP may be operable to multiplex data between higher layer protocols, segment and reassemble packages, and manage multicast data transmission.

BLE uses three fixed channels (one for signaling CH, one for Security Manager, and one for Attribute protocol).

On the other hand, BR/EDR (Basic Rate/Enhanced Data Rate) uses a dynamic channel and supports protocol service multiplexer, retransmission, streaming mode, and the like.

A Security Manager (SM) 450 is a protocol for authenticating devices and providing key distribution.

ATT (Attribute Protocol, 440) defines rules for accessing data of a counterpart device in a server-client structure. There are 6 message types (Request, Response, Command, Notification, Indication, Confirmation) in ATT.

That is, ① Request and Response message: The Request message is a message for requesting specific information from the client device to the server device, and the Response message is a response message to the Request message and refers to a message transmitted from the server device to the client device.

② Command message: This is a message transmitted from the client device to the server device to instruct a specific operation command. The server device does not transmit a response to the command message to the client device.

③ Notification message: This is a message sent from the server device to the client device to notify such as an event. The client device does not transmit a confirmation message for the notification message to the server device.

④ Indication and Confirm message: This is a message sent from the server device to the client device to notify such as an event. Unlike the notification message, the client device transmits a confirmation message for the indication message to the server device.

GAP (Generic Access Profile) is a newly implemented layer for BLE technology, and is used to control role selection and multi-profile operation for communication between BLE devices.

In addition, GAP is mainly used for device discovery, connection creation, and security procedures, defines a method of providing information to users, and defines the following attribute types.

① Service: Defines the basic operation of the device as a combination of behaviors related to data

② Include: Defines the relationship between services

③ Characteristics: Data values used in the service

④ Behavior: Computer-readable format defined as UUID (Universal Unique Identifier, value type)

GATT-based Profiles are profiles that depend on GATT and are mainly applied to BLE devices. GATT-based Profiles can be Battery, Time, FindMe, Proximity, Time, Object Delivery Service, etc. Details of GATT-based Profiles are as follows.

Battery: How to exchange battery information

Time: How to exchange time information

FindMe: Provides alarm service according to distance

Proximity: how to exchange battery information

GATT may be operable as a protocol that describes how ATT is used in the configuration of services. For example, GATT may be operable to specify how ATT attributes are grouped together into services, and may be operable to describe characteristics associated with services.

Thus, GATT and ATT can use features to describe the status and services of a device, how they relate to each other and how they are used.

The controller stack includes a physical layer (490), a link layer (480), and a host controller interface (470).

The physical layer (wireless transmission/reception module, 490) is a layer that transmits and receives 2.4 GHz radio signals and uses GFSK (Gaussian Frequency Shift Keying) modulation and a frequency hopping technique consisting of 40 RF channels.

Link layer 480 transmits or receives Bluetooth packets.

In addition, the link layer performs advertising and scanning functions using 3 advertising channels (channels 37, 38, and 39), creates a connection between devices, and sends and receives data packets of up to 42 bytes through 37 data channels. provides

HCI (Host Controller Interface) provides an interface between the host stack and the controller stack, allowing the host stack to provide commands and data to the controller stack, and the controller stack to provide events and data to the host stack.

Hereinafter, procedures of Bluetooth Low Energy (BLE) technology will be briefly reviewed.

The BLE procedure may be divided into a device filtering procedure, an advertising procedure, a scanning procedure, a discovering procedure, and a connecting procedure.

Device Filtering Procedure

The device filtering procedure is a method for reducing the number of devices performing responses to requests, instructions, notifications, etc. in the controller stack.

When a request is received by all devices, since it is not necessary to respond to it, the controller stack can control the BLE controller stack to reduce power consumption by reducing the number of requests sent.

An advertising device or a scanning device may perform the above device filtering procedure to restrict devices receiving advertising packets, scan requests, or connection requests.

Here, the advertisement device refers to a device that transmits an advertisement event, that is, performs an advertisement, and is also referred to as an advertiser.

A scanning device refers to a device that performs scanning and a device that transmits a scan request.

In BLE, when a scanning device receives some advertising packets from an advertising device, the scanning device should send a scan request to the advertising device.

However, if the device filtering procedure is used and transmission of the scan request is unnecessary, the scanning device may ignore advertisement packets transmitted from the advertisement device.

A device filtering procedure may also be used in the connection request process. If device filtering is used in the connection request process, it is not necessary to transmit a response to the connection request by ignoring the connection request.

Advertising Procedure

The advertising device performs an advertising procedure to perform non-directional broadcasting to devices within the area.

Here, non-directional broadcast refers to broadcast in all (all) directions rather than broadcast in a specific direction.

In contrast, directional broadcast refers to broadcasting in a specific direction. Non-directional broadcasting occurs between an advertising device and a device in a listening (or listening) state (hereinafter referred to as a listening device) without a connection procedure.

The advertising procedure is used to establish a Bluetooth connection with a nearby initiating device.

Alternatively, the advertising procedure may be used to provide periodic broadcast of user data to scanning devices that are listening on the advertising channel.

In the advertisement process, all advertisements (or advertisement events) are broadcast through advertisement physical channels.

Advertising devices may receive scan requests from listening devices that are listening to obtain additional user data from the advertising device. The advertising device transmits a response to the scan request to the device that sent the scan request through the same advertising physical channel as the advertising physical channel that received the scan request.

Broadcast user data sent as part of advertisement packets is dynamic data, whereas scan response data is generally static data.

An advertising device may receive a connection request from an initiating device on an advertising (broadcast) physical channel. If the advertising device uses a connectable advertising event and the initiating device is not filtered by the device filtering procedure, the advertising device stops advertising and enters a connected mode. The advertising device may start advertising again after the connection mode.

Scanning Procedure

A device that performs scanning, that is, a scanning device performs a scanning procedure to listen to a non-directional broadcast of user data from advertising devices using an advertising physical channel.

The scanning device transmits a scan request to the advertising device through an advertising physical channel to request additional user data from the advertising device. The advertising device transmits a scan response, which is a response to the scan request, including additional user data requested by the scanning device through the advertising physical channel.

The scanning procedure may be used while being connected to another BLE device in a BLE piconet.

If the scanning device receives a broadcast advertising event and is in an initiator mode capable of initiating a connection request, the scanning device transmits a connection request to the advertising device through the advertising physical channel, thereby and start a Bluetooth connection.

When the scanning device sends a connection request to the advertising device, the scanning device stops initiator mode scanning for additional broadcasting and enters a connection mode.

Discovering Procedure

Devices capable of Bluetooth communication (hereinafter, referred to as 'Bluetooth devices') perform advertising procedures and scanning procedures to discover nearby devices or to be discovered by other devices within a given area.

The discovery procedure is performed asymmetrically. A Bluetooth device trying to find other devices around it is called a discovering device, and it listens to find for devices advertising scannable advertising events. A Bluetooth device discovered and available from other devices is called a discoverable device, and actively broadcasts an advertisement event through an advertisement (broadcast) physical channel so that other devices can scan it.

Both the discovering device and the discoverable device may already be connected to other Bluetooth devices in the piconet.

Connecting Procedure

The connection procedure is asymmetric, and the connection procedure requires that another Bluetooth device perform a scanning procedure while a specific Bluetooth device performs an advertising procedure.

That is, the advertisement process can be targeted, so that only one device will respond to the advertisement. After receiving an accessible advertising event from the advertising device, connection may be initiated by transmitting a connection request to the advertising device through an advertising (broadcast) physical channel.

Next, operation states in the BLE technology, that is, an advertising state, a scanning state, an initiating state, and a connection state will be briefly reviewed.

Advertising State

The Link Layer (LL) enters the advertised state, at the direction of the host (stack). When the link layer is in the advertising state, the link layer transmits advertising packet data units (PDUs) in advertising events.

Each advertising event consists of at least one advertising PDU, and the advertising PDUs are transmitted through the used advertising channel indices. The advertising event may be terminated when the advertising PDU is transmitted through each of the advertising channel indexes used, or the advertising event may be terminated earlier if the advertising device needs to secure space for performing other functions.

Scanning State

The link layer enters the scanning state at the direction of the host (stack). In the scanning state, the link layer listens for advertising channel indices.

There are two types of scanning states: passive scanning and active scanning, and each scanning type is determined by the host.

A separate time or advertising channel index for performing scanning is not defined.

During the scanning state, the link layer listens for an advertising channel index during the scanWindow duration. The scanInterval is defined as the interval (interval) between the starting points of two consecutive scan windows.

The link layer SHOULD listen for completion of all scan intervals in the scan window, as directed by the host, if there are no scheduling conflicts. In each scan window, the link layer has to scan different advertising channel indices. The link layer uses all available advertising channel indices.

When passive scanning, the link layer only receives packets and does not transmit any packets.

When active scanning, the link layer listens to the advertising device for advertising PDUs and depending on the advertising PDU type it can request additional information about the advertising device.

Initiating State

The link layer enters the initiation state at the direction of the host (stack).

When the link layer is in the initiating state, the link layer listens for advertising channel indices.

During the initiation state, the link layer listens to the advertising channel index during the scan window period.

connection state

The link layer enters the connected state when the device making the connection request, that is, when the initiating device sends a CONNECT_REQ PDU to the advertising device or when the advertising device receives a CONNECT_REQ PDU from the initiating device.

After entering the connected state, the connection is considered to be created. However, it need not be considered to be established at the time when the connection enters the connected state. The only difference between a newly created connection and an established connection is the link layer connection supervision timeout value.

When two devices are connected, they act in different roles.

A link layer performing a master role is called a master, and a link layer performing a slave role is called a slave. The master controls the timing of the connection event, and the connection event refers to the timing of synchronization between the master and the slave.

Master (Central) is a device that periodically scans the Connectable Advertising Signal to establish a connection with other devices (slave, peripheral) and requests connection to the appropriate device.

Also, once the master device is connected with the slave device, it sets timing and leads periodic data exchange.

Timing here can be a hopping rule set by two devices to send and receive data on the same channel every time.

A Slave (Peripheral) device is a device that periodically transmits a Connectable Advertising Signal in order to establish a connection with another device (Master).

Therefore, when the master device that receives it sends a connection request, it accepts it and establishes a connection.

After the slave device establishes a connection with the master device, it periodically exchanges data while hopping the Channel together according to the timing specified by the master device.

Hereinafter, packets defined in the Bluetooth interface will be briefly reviewed. BLE devices use packets defined below.

Packet Format

The Link Layer has only one packet format used for both Advertising Channel Packets and Data Channel Packets.

Each packet consists of four fields: Preamble, Access Address, PDU, and CRC.

When one packet is transmitted on an advertising physical channel, the PDU will be an advertising channel PDU, and when one packet is transmitted on a data physical channel, the PDU will be a data channel PDU.

Advertising Channel PDU (PDU)

An advertising channel PDU (PACKet Data Unit) has a 16-bit header and payloads of various sizes.

The PDU type field of the advertising channel PDU included in the header indicates the PDU type as defined in Table 1 below.

PDU Type Packet Name 0000 ADV-IND 0001 ADV_DIRECT_IND 0010 ADV_NONCONN_IND 0011 SCAN_REQ 0100 SCAN_RSP 0101 CONNECT_REQ 0110 ADV_SCAN_IND 0111-1111 Reserved

Advertising PDUs

The advertising channel PDU types below are referred to as advertising PDUs and are used in specific events.

ADV_IND: chainable non-directional advertising event

ADV_DIRECT_IND: directive advertising events that can be chained

ADV_NONCONN_IND: non-connectable non-direction advertising event

ADV_SCAN_IND: scannable non-directional ad event

The PDUs are transmitted in the link layer in an advertising state and received by the link layer in a scanning state or initiating state.

Scanning PDUs

The advertising channel PDU type below is called a scanning PDU and is used in the conditions described below.

SCAN_REQ: Sent by the link layer in the scanning state and received by the link layer in the advertising state.

SCAN_RSP: Sent by the link layer in the advertising state and received by the link layer in the scanning state.

Initiating PDUs

The advertising channel PDU type below is called an initiation PDU.

CONNECT_REQ: Sent by the link layer in the initiating state and received by the link layer in the advertising state.

Data Channel PDUs

A data channel PDU has a 16-bit header, payloads of various sizes, and may include a Message Integrity Check (MIC) field.

As discussed above, the procedures, states, packet formats, etc. in BLE technology can be applied to perform the methods proposed in this specification.

5 is a diagram showing an example of a GATT Profile structure of Bluetooth low energy.

Referring to FIG. 5, a structure for exchanging profile data of Bluetooth low energy can be seen.

Specifically, GATT (Generic Attribute Profile) defines a method for exchanging data using services and characteristics between Bluetooth LE devices.

In general, a peripheral device (for example, a sensor device) serves as a GATT server and has definitions for services and characteristics.

To read or write data, the GATT client sends a data request to the GATT server, and all transactions are initiated from the GATT client and received a response from the GATT server.

The GATT-based operation structure used in Bluetooth LE is based on Profile, Service, and Characteristic, and can form a vertical structure as shown in FIG. 5.

The Profile consists of one or more services, and the service may consist of one or more characteristics or other services.

The service serves to divide data into logical units and may include one or more characteristic or other services.

Each service has a 16-bit or 128-bit identifier called UUID (Universal Unique Identifier).

The characteristic is the lowest unit in the GATT-based operation structure. The characteristic includes only one data and has a 16-bit or 128-bit UUID similar to the service.

The characteristic is defined as a value of various pieces of information, and requires one attribute to contain each piece of information. The above characteristics may use several contiguous attributes.

The attribute is composed of four components and has the following meaning.

- handle: address of property

- Type: the type of attribute

- Value: the value of the attribute

- Permission: Permission to access properties

Hereinafter, a connection procedure in Bluetooth LE will be briefly reviewed, and as an example thereof, a method for providing an object transmission service in Bluetooth LE will be reviewed.

6 is a flowchart illustrating an example of a connection procedure method in Bluetooth low energy technology.

The server transmits an advertisement message to the client through three advertisement channels (channels 37, 38, and 39) (S610).

The server may be called an advertiser before connection, and may be called a master after connection. As an example of the server, there may be sensors (temperature sensors, etc.).

In addition, the client may be called a scanner before connection, and may be called a slave after connection. An example of the client may include a smartphone.

As seen, Bluetooth communicates by dividing a total of 40 channels through the 2.4GHz band. Among the 40 channels, 3 channels are advertising channels, and are used for exchanging packets exchanged to establish a connection, including various advertising packets.

The remaining 37 channels are data channels and are used for data packet exchange after connection.

After receiving the advertisement message, the client may transmit a Scan Request to the server to acquire additional data (eg, server device name, etc.) from the server.

Then, the server transmits a scan response including the remaining data as a response to the scan request to the client.

Here, Scan Request and Scan Response are types of advertisement packets, and advertisement packets may include only user data of 31 bytes or less.

Therefore, if the size of the data is greater than 31 bytes, but the overhead is too large to send the data by establishing a connection, the data is divided and sent twice using Scan Request/Scan Response.

Next, the client transmits a connection request for establishing a Bluetooth connection with the server to the server (S620).

Through this, a Link Layer (LL) connection is established between the server and the client.

Then, the server and the client perform a security establishment procedure.

The security establishment procedure may be interpreted as Secure Simple Pairing or performed including it.

That is, the security establishment procedure may be performed through Phase 1 to Phase 3.

Specifically, a pairing procedure (Phase 1) is performed between the server and the client (S630).

In the pairing procedure, the client transmits a pairing request to the server, and the server transmits a pairing response to the client.

Next, as Phase 2, legacy pairing or secure connections are performed between the server and the client (S640).

Next, as SSP Phase 3, a key distribution procedure is performed between the server and the client (S750).

Through this, a secure connection is established between the server and the client, and encrypted data can be transmitted and received.

7 is a flowchart illustrating an example of a method of providing an object transfer service in Bluetooth low energy technology.

Object Delivery Service or Object Transfer Service refers to a service supported by BLE to transmit/receive objects or data such as bulk data in Bluetooth communication.

In order to establish a Bluetooth connection between the server device and the client device, an advertisement process and a scanning process corresponding to steps S710 to S730 are performed.

First, the server device transmits an advertisement message to the client device to notify information related to the server device including the object transmission service (S710).

The advertisement message may be expressed as an advertisement PACKet Data Unit (PDU), advertisement packet, advertisement, advertisement frame, advertisement physical channel PDU, and the like.

The advertisement message may include service information provided by the server device (including service name), the name of the server device, manufacturer data, and the like.

Also, the advertisement message may be transmitted to the client device in a broadcast method or a unicast method.

Thereafter, the client device transmits a scan request message to the server device in order to obtain more detailed information related to the server device (S720).

The scan request message may be expressed as a scanning PDU, a scan request PDU, a scan request, a scan request frame, or a scan request packet.

Thereafter, the server device transmits a scan response message to the client device in response to the scan request message received from the client device (S730).

The scan response message includes server device related information requested by the client device. Here, the server device-related information may be an object or data transmittable by the server device in relation to providing an object transmission service.

When the advertisement process and the scanning process end, the server device and the client device perform a connection initiating process and a data exchange process corresponding to steps S740 to S770.

Specifically, the client device transmits a Connect Request message to the server device for a Bluetooth communication connection with the server device (S740).

The connection request message may be expressed as a connection request PDU, an initiation PDU, a connection request frame, or a connection request.

Through step S740, a Bluetooth connection is established between the server device and the client device, and then the server device and the client device exchange data. During the data exchange process, data may be transmitted and received through a data channel PDU.

The client device transmits an object data request to the server device through a data channel PDU (S750). The data channel PDU may be expressed as a data request message or data request frame.

Then, the server device transmits the object data requested by the client device to the client device through a data channel PDU (S760).

Here, the data channel PDU is used to provide data or request data information to a counterpart device in a manner defined in the Attribute protocol.

Thereafter, when data change occurs in the server device, the server device transmits data change indication information through a data channel PDU to the client device to inform the change of data or object (S770). .

Then, the client device requests changed object information to the server device to find the changed data or changed object (S780).

Thereafter, the server device transmits object information changed in the server device to the client device in response to the changed object information request (S790).

Thereafter, the client device finds a changed object through a comparative analysis of the received changed object information and object information currently possessed by the client device.

However, the client device repeatedly performs steps S780 and S790 until the changed object or data is found.

Thereafter, when the connection state between the host device and the client device does not need to be maintained, the host device or the client device may disconnect the corresponding connection state.

8 is a flowchart illustrating an example of a connection procedure method in Bluetooth BR/EDR technology.

As shown in FIG. 8, a connection procedure in Bluetooth BR/EDR may consist of the following steps.

The connection procedure may also be expressed as a pairing procedure.

A Bluetooth pairing procedure is divided into only a Standby State and a Connected State.

A device for which Bluetooth pairing is completed enters the connected state, and a device for which connection is terminated operates in a standby state.

In addition, Bluetooth devices may perform a reconnection procedure to reconnect after being connected to a specific device through a connection procedure.

The reconnection procedure may be performed through the same procedure as the connection procedure.

Specifically, the master device basically enters a standby state when power is input.

Thereafter, an inquiry procedure (S811) for discovering peripheral devices for Bluetooth connection is performed.

That is, the master device can become an inquiry state in order to discover nearby connectable devices (slaves), and the slave device has an ID transmitted by surrounding devices (masters) in an inquiry state. In order to receive a packet, it may be in an inquiry scan state.

The master device in the inquiry state transmits an inquiry message using an ID packet once or every predetermined time interval in order to discover nearby connectable devices.

The ID packet may be a General Inquiry Access Code (GIAC) or a Dedicated Inquiry Access Code (DIAC).

After receiving the ID packet GIAC or DIAC transmitted by the master device, the slave device transmits a frequency hopping sequence (FHS) to perform Bluetooth pairing with the master device.

In addition, if necessary, when data to be transmitted exists, an extended inquiry response (hereinafter referred to as EIR) may be transmitted to the master device.

If a nearby connectable Bluetooth device is found through the inquiry procedure, a paging procedure (S812) is performed.

The paging procedure (S812) refers to a step of performing an actual connection by synchronizing a hopping sequence with addresses and clock information when a nearby connectable Bluetooth device is found through the inquiry procedure.

Specifically, the paging procedure includes (1) the master device sending a Page to the slave device, (2) the slave device sending a Slave Page Response to the master device, (3) the master device sending the Master Page to the slave device. It can be divided into steps of sending a response.

When the inquiry procedure and the paging procedure are completed, the master device and the slave device perform a security establishment step (S814), and then perform an L2CAP connection and service discovery step (S815).

Before performing the security establishment step, the master device and the slave device exchange I (Input) / O (Output) capabilities with each other (S813).

This can be done through I/O capability request and I/O capability response.

In addition, the security establishment step may include a Secure Simple Pairing procedure to be described later or may be interpreted in the same meaning.

The L2CAP (Logical Link Control and Adaption Protocol) is a packet-based protocol and has similar characteristics to the UDP protocol. It has a packet size of up to 672 bytes by default, but can be changed up to 65,535 bytes when communication starts.

After performing the L2CAP connection and service discovery steps, the master device may transmit data input from the user to the slave device (S816).

When there is no data exchange between the master device and the slave device that have performed such a connection procedure for a certain period of time, they are switched to a sleep state to prevent energy consumption, and the connection state is terminated.

After that, the master device and the slave device perform a reconnection procedure to transmit/receive data again.

The reconnection procedure may be performed through the same steps as the previous salpin connection procedure.

Mesh Network

Hereinafter, a mesh network will be described.

9 is a schematic diagram illustrating an example of a Bluetooth mesh network to which the present specification can be applied.

As shown in FIG. 9, the mesh network refers to a network in which a plurality of devices are connected like a mesh through Bluetooth to transmit and receive data.

In the Bluetooth mesh network technology, one or more devices relaying (or relaying) a message exist between a source device 200-1 that transmits data and a destination device 200-2 that receives data.

At this time, the source device and the destination device may be referred to as edge nodes (Edge node, 200-1, 200-2), and one or more devices that relay messages in the middle are relay nodes that relay messages. ) can be called.

Alternatively, the devices 200 - 1 and 200 - 2 having mobility may be devices whose positions are easily changed, and devices fixed without mobility in an initially installed state may be configured.

Each relay node contains a message cache of recently received messages. If a received message already exists in the message cache, the message is not relayed.

However, if the received message does not exist in the message cache, the message is relayed and the message is stored in the message cache.

An edge node is generally powered by a battery, and normally exists in a sleep state, but can be interacted with or periodically woken up.

The edge node may process the received message if the following conditions are satisfied.

- The message does not exist in the message cache.

- The message is authenticated by a known network key.

- When the destination of the message is the unicast address of the edge node, or the broadcast address or group address is the address where the edge node belongs.

A relay node is a device that is generally supplied with main power, is always awake, and can transmit received data for other nodes.

A relay node can retransmit a received message to another node if the following conditions are satisfied.

- The message does not exist in the message cache.

- The message is authenticated by a known network key.

- When a field indicating whether or not a message is relayed (for example, relay count value) is a value that allows relaying.

- When the destination address is not a unicast address assigned to the relay node.

In the Bluetooth mesh network, a flooding method and a routing method can be classified according to the data transmission method of the relay nodes 200-3 and 200-4.

The flooding method refers to a method in which relay nodes that receive messages use the characteristics of radio waves spreading in all directions in the air and shoot them back into the air.

That is, the source device 200-1 transmits a message to the relay nodes 200-3 and 200-4 through broadcast channels, and the relay nodes receiving the message transmit the message to adjacent relay nodes again, This refers to a method of transmitting to the destination device 200-2.

In the floating method, a broadcasting channel is used to receive and retransmit a message, and the transmission range of the message can be expanded.

The floating mesh network is a dynamic network, and in the floating mesh network, a device may receive and transmit (or retransmit) a message at any time as long as the density of the device is satisfied.

The floating technique has an advantage of being easy to implement, but since messages are transmitted without directionality, a scalability problem may occur as the network expands.

That is, in the floating mesh network, when a device transmits a message, a plurality of devices receive the message and transmit the received message to another plurality of devices.

To prevent this, the number of devices constituting the mesh network may be adjusted between 100 and 1000, and the exact number of devices may be determined by various factors.

For example, it may be determined by network capacity, traffic load of data sources, network latency and reliability requirements, and the like.

In addition, unlike the routing method, the flooding method can easily deliver messages without the cost of building a routing table, but all of the relay devices 200-3 and 200-4 that have received the message retransmit the received message again. As a result, there is a disadvantage of increasing network traffic.

In the routing method, the source device 200-1 transmits a message to a specific relay node, and the specific relay node that has received the message has information of another relay node or destination node 200-2 to re-send the message and transmits the message. will send

The routing method uses a broadcasting channel or a point-to-point connection method for message reception and retransmission.

In addition, the routing device receiving the message in the routing method determines the best routing route(s) for transmitting the message to an intermediate device or a destination device, and which route to transmit the message to based on the determined routing table. decide whether

The routing method has the advantage of being scalable, but since each node must transmit messages while maintaining routing tables, complexity increases as messages increase, requires a lot of memory, and is less expensive than the flooding method. The downside is that it is dynamic and more difficult to implement.

10 is a diagram illustrating an example of a protocol stack of a Bluetooth mesh network to which the present specification can be applied.

Referring to FIG. 10, the protocol stack of the mesh network is composed of a bearer layer 81, a network layer 82, a transport layer 83, and an application layer 84.

The bearer layer 81 defines how messages are transmitted between nodes. That is, the bearer through which the message is transmitted is determined in the mesh network.

In the mesh network, an advertising bearer and a GATT bearer for message transmission exist.

The network layer 82 defines how messages are sent to one or more nodes in a mesh network and the format of network messages transmitted by the bearer layer 81.

In addition, the network layer 82 defines whether messages are to be relayed or forwarded and how network messages are authenticated and encrypted.

The transport layer 83 defines encryption and authentication of application data by providing confidentiality of application messages.

The application layer 84 defines a method, application operation code (Opcode), and parameters related to how an upper layer application uses the transport layer 73.

11 is a flowchart illustrating an example of a method for a device to which the present specification can be applied to participate in a Bluetooth mesh network.

In order for a new device or an unprovisioned device to join and operate in the mesh network, it must go through a provisioning procedure.

The provisioning procedure refers to a procedure for authenticating an unauthenticated device and providing basic information (eg, a unicast address, various keys, etc.) for participating in a mesh network.

That is, the provisioning procedure is a procedure for providing information for a mesh network provisioner (the second device 400) to participate in the mesh network, and through the provisioning procedure, the first device 300 connects to the network It is possible to obtain the address, keys, device identifier, and various information for operating as part of the mesh network.

The provisioning procedure includes an invitation step, an exchanging public key step, an authentication step, and a distribution of provisioning step.

The provisioning procedure may be performed through various types of bearers. For example, it may be performed by an advertising-based bearer, a mesh provisioning service-based bearer, or a mesh-based bearer.

The advertisement-based bearer is a bearer that is essentially established, and when the advertisement-based bearer is not supported or provisioning data cannot be transmitted through the advertisement-based bearer, the provisioning service-based bearer or mesh-based bearer Can be used in provisioning procedures.

The bearer based on the provisioning service means a bearer for exchanging provisioning data through the GATT Protocol of the existing Bluetooth LE, and the bearer based on the mesh means that the first device 300 and the second device 400 directly It means a bearer that can send and receive provisioning data through a mesh network when it does not exist in a distance that can send and receive data.

A procedure for establishing a bearer based on the advertisement will be discussed later.

After the bearer is established between the first device 300 and the second device 400, the first device 300 may be provisioned through the following provisioning procedure.

Invitation Step

The invitation step starts when the second device 400 scans the first device 300 . The first device transmits a beacon message to the second device 400 (S1110). The beacon message includes the UUID of the first device 300 .

The second device 400 scanning the first device 300 through the beacon message transmits an invite message to the first device 300 (S1120).

The invitation message asks whether the first device 300 will perform a provisioning procedure, and if the first device 300 does not want to perform the provisioning procedure, the invitation message is ignored.

However, when the first device 300 wants to perform the provisioning procedure, that is, when it wants to participate in a mesh network, the first device 300 transmits a capability message in response thereto. (S1130).

The capability message includes information indicating whether the first device 300 supports setting of a security algorithm, a public key, whether a value can be output to the user, and whether a value can be input from the user. It may include information indicating a .

Exchanging Public Key Step

Then, the second device 400 transmits a start message for starting provisioning to the first device 300 (S1140).

If a public key cannot be used using out-of-band technology, the second device 400 and the first device 300 exchange public keys (S1150, S1160).

However, when the public key is available through an out-of-band mechanism, the second device 400 transmits an ephemeral public key to the first device 300, and the first device 300 The static public key can be read using an out-of-band technique from

Thereafter, the second device 400 authenticates the first device 300 by performing an authentication procedure with the first device 300 (S1170).

Distribution of Provisioning Data Step

When the first device 300 is authenticated, the second device 400 and the first device 300 calculate and generate a session key.

Then, the second device 400 transmits provisioning data to the first device 300 (S1180).

The provisioning data may include an application key, a device key, a network key, an IVindex, and a unicast address.

Upon receiving the provisioning data, the first device 300 transmits a completion message in response thereto, and the provisioning procedure ends (S1190).

Direction Finding

Bluetooth proximity solutions and positioning systems currently use signal strength to estimate distance.

A new direction finding feature in the Bluetooth Core Specification v5.1 enables Bluetooth devices to determine the direction of a Bluetooth signal transmission.

This new feature provides two methods to determine the angle at which a Bluetooth signal is transmitted with high accuracy. The two methods are called Angle of Arrival (AoA) and Angle of Departure (AoD).

Each technology requires that one of the two communication devices has an array of multiple antennas. The antenna array is included in the receiving device when using the AoA method and included in the transmitting device when using AoD.

12 shows an example of an arrival angle (AoA) and a departure angle (AoD) to which the method proposed in this specification can be applied.

In particular, FIG. 12(a) is a diagram showing an example of an arrival angle, and FIG. 12(b) is an example of a departure angle.

Bluetooth Core Spec. v5.1 provides the capability to generate data to the receiving device's Bluetooth Low Energy (BLE) controller that can be used to calculate the heading angle for the transmitting device. This Bluetooth Core Spec. Adding direction finding in v5.1 is the first of several steps on the Bluetooth roadmap that will ultimately enable major enhancements to Bluetooth location services. Associated Profiles are released, and Bluetooth developers are taking new directions to create high-precision, interoperable positioning systems such as real-time locating systems (RTLS) and indoor positioning systems (IPS). You will develop your find controller abilities. The new direction finding feature has the potential to improve Bluetooth proximity solutions by determining device orientation, especially in direction item finding and point of interest information solutions.

The Bluetooth direction finding feature uses In-Phase and Quadrature (IQ) sampling to measure the phase of a radio wave incident on an antenna at a given time. In the AoA approach, the sampling process is applied to each antenna in the antenna array one at a time and in an appropriate sequence dependent on the array design.

The sampled data is passed up the stack through the Host Controller Interface (HCI), and it is possible to apply the appropriate algorithm to the sampled data to calculate the orientation from one device to another. The algorithm for calculating angles from IQ samples is Core Spec. Not defined in v5.1. Once the associated profiles are available, the application developer has the opportunity to implement an algorithm suitable for the intended use case.

To support the use of IQ samples and IQ sampling in a higher layer of the stack, the link layer (LL) and HCI have been changed, respectively.

A new field called CTE (Constant Tone Extension) is defined in the link layer (see FIG. 13). The purpose of the CTE field is to provide constant frequency and wavelength signal material upon which IQ sampling can be performed. This field contains a sequence of ones, the normal whitening process is not applied, and it is not included in the CRC calculation.

13 is a diagram showing an example of a CTE field.

It can be seen that the packet of FIG. 13 includes a preamble field, an access-address field, a PDU and a CRC, and optionally includes a CTE field. CTE can be used in both connectionless and connection-oriented scenarios. For connectionless use, a periodic advertising function is required (critical timing in the sampling process is important), and a CTE is added to the AUX_SYNC_IND PDU. For connection-oriented use, new PDUs LL_CTE_REQ and LL_CTE_RSP have been defined. In either case, there is a new HCI PDU that can compose various aspects of CTE PDUs such as CTE length, antenna switching pattern length, and antenna ID.

GATT caching enhancement

All Bluetooth LE connected devices use GATT. Thus, the topic of GATT caching is relevant to various device types. The GATT apparatus includes a database known as an attribute table. The attribute table contains GATT service, characteristic, descriptor structure details and values, and is the key to how a GATT based Bluetooth LE device works. Entries in the attribute table are identified by attribute handles. A GATT client must perform a procedure known as service discovery to obtain detailed information about the attribute table of the remote GATT server device to which the client is connected. The GATT client can use these details, including identifying attribute handles, in subsequent ATT (Attribute Protocol) interactions with the server.

14 is a diagram illustrating an example of service discovery and attribute caching.

Some devices do not change their attribute table structure during their lifetime. In the attribute table, GATT services, characteristics and descriptors are always the same, and only some values of the characteristics or descriptors are changed. Other devices change the attribute table from time to time. Service discovery (or service retrieval) takes time and consumes energy. Thus, the Bluetooth Core Specification v5.1 defines an attribute caching strategy that allows clients to skip service discovery if nothing has changed. Previously, caching and client/server attribute table synchronization was only controlled using service-altering attributes, which can be found in the Generic Attribute Service.

The GATT server can notify connected clients that the attribute table has changed by sending an ATT indication to the client. The client responds with an ATT confirmation and performs service discovery to synchronize its attribute cache with the server's attribute cache.

To avoid the need for the GATT server to keep track of all clients that have ever connected to the GATT server, and to keep track of whether each client has been notified of the latest attribute table change, previously Core Spec. A service discovery had to be performed every time a disconnected) client and server connected.

This rule can cause energy efficiency and user experience issues for some product types.

Additionally, there was no additional state management performed regarding the client's versus the server's view of the attribute table other than a single attempt to inform the client that the attribute table has changed using the ATT Service Changed indication.

This approach allowed for race conditions in the communication between the client and server regarding attribute table changes.

A typical ATT interaction was allowed to exist. Here, after the client connects to the server, it is possible to time out while waiting for the service changed indication, proceed with sending a normal ATT PDU, and then the client receives the service changed indication.

Improved Caching Strategy

Bluetooth Core Spec. v5.1 changes the way attribute caching and cache synchronization are approached by GATT clients and servers. This allows clients that do not have a trusted relationship with the server to maintain the client's attribute cache over the connection, and solves the previously described race condition issue, providing significant user experience and energy efficiency improvements.

Two new attributes are introduced, each a member of the Generic Attribute Service: Database Hash and Client Supported Feature. Clients that do not have a trust relationship with the server MAY cache the attribute table over the connection if the client supports the new database hash property as indicated by the client updating a flag in the server's Client Support Features property.

The database hash property allows clients to ask the server if something has changed without relying on the server to inform them using a service changed indication. The server maintains the value of the database hash property, which is a hash value computed from the appropriate side of the property table. The client reads the value immediately after establishing the connection.

The client may cache the database hash value and subsequently use the database hash value to determine whether the remote attribute table has changed. If the remote attribute table is changed, the client performs service discovery again.

If the remote attribute table has not changed, the client does not need to perform service discovery.

This provides major user-experience and energy efficiency benefits for some device types.

Also, the client can infer that the device being connected is of the same type as the device it was previously connected to and whose attribute table has already been cached by the client. If the connected device's database hash is the same as the one linked to the client's property cache, and other details such as device manufacturer are the same, then the client performs a service discovery for the connected device as the property cache obtained from the other device already contains the same data. We can conclude that there is no need to do this.

For some applications, this change is of considerable value. For example, consider a Bluetooth smart lock.

Here, a smartphone or other client device interacts with a door in the building to authenticate and open the door for the user as they approach.

Service discovery only needs to be performed when the user tries to walk through the door for the first time using the smart lock. The user may notice a delay on the door unlocking during this first opportunity, but not necessarily every time the user subsequently approaches the door from the building service discovery, the user experiences a near-instantaneous response from the smart lock. will do

better state management

The state machine defines whether the client's view of the attribute table and the server's view of the attribute table are synchronized and whether the client needs to perform service discovery.

The revised spec. for attribute caching introduces the strictly defined concept of Robust Caching, which formalizes this state machine and introduces a mechanism for using it.

A client can be in a change-aware state or a change-unaware state. Spec. describes the exact rules for transitioning to the appropriate state and how to operate in each of the two states.

Of particular note is the new «Database Out Of Sync» ATT error response that servers can return if it determines that the client attribute table cache is out of sync with the server. The server ignores all ATT commands received from clients during the change-unaware state.

A number of events occur, including a server receiving an ATT acknowledgment of a previously sent service change indication, or a server notifying the client with a << Database Out Of Sync >> error and subsequently receiving another ATT PDU from the client. The state of the client may transition to a change-aware state.

From the client's point of view, moving into the change-unware state will render the attribute cache invalid and will not be used. It continues to be considered invalid until the client's attribute cache and the server's attribute cache are synchronized once again.

Advertising enhancement 1: randomized advertising channel indexing

Bluetooth Core Spec. In v5.0, an advertising event is defined as "one or more advertising PDUs transmitted on the primary advertising channel starting with the first used advertising channel index and ending with the last used advertising channel index".

In practice, this means that when all three channels are in use (which often happens), advertising uses channels 37, 38, and 39 in strict order.

In order to reduce the possibility of continuous packet collisions in which two or more devices advertise on the same channel in overlapping time periods, Bluetooth Core Spec. v5.0 requires that the time between successive advertising events include a random delay between 0 and 10 ms.

15 shows an example of using an advertising channel according to the Bluetooth Core Specification v5.0 with a fixed sequence of advertising channels.

Improved Packet Collision Avoidance

In Bluetooth Core Spec.v5.0, devices in the advertised state are no longer required to select advertising channels in a strict, unchanging order, starting with the lowest channel index used and ending with the highest channel index.

Random selection of channel indices is allowed. Randomization of advertising channel indices further reduces the possibility of advertising packet collisions.

Applications that use advertising to perform connectionless communication can benefit from improved scalability and reliability in busy wireless environments by implementing this change to advertising channel index selection.

16 is a diagram illustrating an example of using an advertising channel according to Bluetooth Core Specification v5.1 using a randomized channel index sequence.

Advertising Improvement 2: Periodic Advertising Sync. Transfer

Bluetooth Core Spec. v5.0 introduces periodic advertising using deterministic scheduling of advertising events, and provides a procedure that devices can use to synchronize other devices' advertising schedules with their scanning.

Synchronization of scanning and advertising timing can increase the energy efficiency of the scanning device and enable some use cases where precise timing is required in data exchange.

To allow periodic advertising and synchronization of the remote device, the remote device advertises an AUX_ADV_IND PDU containing a field called SyncInfo. SyncInfo contains everything the receiving device needs to synchronize with the periodic advertisement of the AUX_SYNC_IND PDU performed by the remote device from that point on.

However, this periodic advertisement synchronization procedure can be a relatively expensive operation.

Some device types with limited power may not be able to afford the energy costs associated with periodic advertisement synchronization procedures or may have duty cycle or scan time limitations that hinder operation.

17 is a diagram illustrating an example of using periodic advertisement synchronization transmission.

The new Periodic Advertising Sync Transfer (PAST) feature allows a relatively unrestricted device to perform a synchronization procedure to another device, then point-to-point Bluetooth Conveys acquired synchronization details for point-to-point Bluetooth Low Energy connections. For example, a smart phone scans for AUX_SYNC_IND packets from a TV, and then sends them to the associated smart watch (smart watch) so that the smart watch can benefit from using periodic advertising and scanning to obtain data from the TV. watch) forwards the connection.

Minor Enhancements

Bluetooth Core Spec. v5.1 includes some minor improvements.

HCI support for debug keys on LE secure connections

LE Secure Association is a Bluetooth pairing procedure that uses the Diffie Hellman key agreement protocol to secure the exchange of a shared secret key during pairing. Diffie Hellman uses asymmetric, elliptic curve cryptography with a public and private key. This makes it impossible to take the shared key and use it for connection tracing and debugging during development and testing.

Bluetooth Core Spec. In v4.2, hard-coded key values were defined for testing purposes. However, if the elliptic curve algorithm is implemented in the controller, there is no way to indicate that the host wants to use it. The latest version of the Bluetooth Core Spec. adds an HCI command that allows the host to instruct the controller to use the value of a debug key. Use cases where the host implements the elliptic curve algorithm itself are not affected by this change.

Sleep clock accuracy update mechanism

Currently, when establishing an LE connection, the master device tells the slave how accurate the master's clock is using the Sleep Clock Accuracy (SCA) field. However, the exact requirements may change depending on the concurrent use cases being handled by the controller.

For example, when another connection with higher clock accuracy requirements is established, it may start at one value but needs to go up one notch. Bluetooth Core Spec. v5.1 provides a new link-layer PDU, LL_CLOCK_ACCURACY_REQ, which can be used to notify attached slaves of new clock accuracy values. This PDU can be transmitted by the master to the slave or by the slave to the master in order for the slave to inform the master of this in the link of their clock accuracy. This feature can lower power consumption in some cases.

The AdvDataInfo (ADI) field is used for expanded advertisement packets. Previously, this *?* field was not allowed in scan response packets. The latest Bluetooth Core Spec. In v5.1, it is allowed to include ADI in scan response packets.

This change clarifies rules related to quality of service (QoS) and flow related to Bluetooth basic rate/enhanced data rate (BR/EDR).

Host Channel Classification for Secondary Ads

The HCI command LE_Set_Host_Channel_Classification allows classification of radio channels as "bad". Previously applied only to connections, now it also applies to secondary advertising channels.

The Ad Set ID (SID) field is used in Extended Advertising Packets. Previously this field was not allowed in scan response packets. Bluetooth Core Spec. In v5.1, it is now possible to include SID in scan response reports.

'Responding to Invalid Behavior' is the latest Core Spec. added to the release.

Generic Health Sensor (GHS) service

The parameters, procedures, and modes used in the GHS service are briefly summarized, and the matters related to the GHS service are examined in more detail.

- GHS Feature Characteristic: As a parameter used in GHS, it means the characteristic for the Collector to grasp the service list and data type.

- Device Info.: As a parameter used in GHS, it can mean the battery capacity of the sensor device, HW type (Service Data measurement method, hospital internal device, installation type device, etc.).

- GHS capability exchange: As a procedure performed in GHS, mainly Sensor's Device Feature Info. and GHS Feature Characteristic information to Collector so that Collector can effectively receive sensor information. Collector devices can change sensor settings as needed (Ex: heart rate information reporting cycle, etc.).

- Service Sleep: As a procedure performed in GHS, the sensor sends a Service Sleep message in consideration of the characteristics of its services (event-type biometric information transmission or periodic biometric information transmission, etc.) and device characteristics (one-time use device, remaining battery status, etc.) can be transmitted, or the next data transmission time can be notified to the Collector by including it in the form of a field in Service Data. Based on this information, Collector can adjust connection parameters, set search window, and reconnection operation.

- Real Time Medical Data Transfer: As a mode performed by GHS, service data is transmitted in real time according to the characteristics of the created bearer.

- Medical Credential Exchange: As a procedure performed by GHS, it is a procedure for exchanging user account-related information between Medical Manager and Collector devices, and information obtained through this can be delivered to sensor devices. (Ex: Broadcasting hashed information based on Account and Key values in Advertising Payload)

- Medical Auto Connection: As a procedure performed by GHS, Medical devices agree on User ID and Connection Configuration at initial connection. Collector can request a connection by checking the GHS AD Type and User ID information among the scanned devices even in a non-connected state.

- Open GHS MR Transfer Channel: This is a procedure performed in GHS, which means a procedure for establishing a link for exchanging MR data between PHD and PHG. It is created by selecting a bearer such as GATT or L2CAP CoC according to the nature of the MR. can do. For example, if the MR needs real-time transmission, it creates an L2CAP CoC or ISO Link.

- MR List Filter: As a parameter required by GHS, among MRs measurable by PHD, MRs to be transmitted in PHG can be set. Also, it is used when filtering only a specific MR in PHG.

- The GHS device status is a parameter required by GHS, and refers to the parameters for identifying the user's PHD status through the server in the remote diagnosis service.

- GHS timestamp: As a parameter required by GHS, the parameter indicating the time when the MR was measured, the PHY Clock held by the RF communication module of the device according to the setting negotiated by the PHD and PHG, or the time stamp information given by the MAC layer ( ISO CH, HADM, etc.) can be used. Time information may be acquired using a separate Application Profile. (Device Time Profile/Service, etc.)

- GHS Time Set Control Point: As a message or procedure executed by GHS, GATT Control Point consists of ATT Write Request and Notification or Indication Message. At this time, it is possible to set the time stamp format and value through the GHS Time Set Control Point.

- MR Priority Filter: As a mode used in GHS, PHG devices in MR Priority Filtering Mode process MRs with high processing priority among the information collected from PHD devices, and increase the priority of BLE Link polling. A priority field may be assigned to a device or to a specific MR type. For example, if the MR Priority of a specific device is high, PHG sets the interval length to the minimum value in the connection parameter setting with the corresponding PHD. Advertising Interval is also set to the minimum value to increase search and connection speed and transmission speed.

- Time Management Negotiation (TMN): A procedure performed by the GHS, through which the PHG and PHD establish who will do the time management. When the location/circumstance of the PHD (general health care mode, emergency mode, etc.) changes, the PHD shares it with the PHG and automatically sets up a new time stamp and operates the device (automatically connects to the pre-installed hospital PHG and provides specific MR information: Exchange of patient basic information) is possible.

- Zone Change: As a parameter required by GHS, the location/circumstance (general health management mode, emergency mode, etc.) of the parameter PHD exchanged in the TMN procedure is changed.

Hereinafter, GHS profiles and services will be reviewed.

Representative scenarios of GHS services and profiles include remote patient monitoring, wider range of wireless sensors in home healthcare, and in-hospital usage of wireless sensors. wireless sensors), a generic health app using a new sensor device, multi-user support, and the like.

In addition, the main characteristics (characteristics) of the GHS are defined in a form that supports ACOM (Abstract Content Model), and there may be a Numeric Observation characteristic, a Sample Array Observation characteristic, a Discrete Observation characteristic, a String Observation characteristic, and the like.

The primary structure of the attribute type is informed through each characteristic UUID (Universally Unique IDentifier), and the Object ID and Object Type are configured in a GATT-based format to support ACOM.

18 is a diagram showing an example of a conceptual diagram of a GHS service structure proposed in this specification.

As shown in FIG. 18, the GHS profile includes GHS service, Device Information Service (DIS) 1.2, to be defined Generic time service, Battery Service (BAS) 1.1, User Data Service (UDS) 1.1, and RCS. (Reconnection Configuration Service)/BMS (Bond Management Service) 1.0 included. Each service included in the GHS profile is first looked at in turn.

GHS service is the core service of Profile. ACOM (Abstract Content Model) Supports communication of Observations (observations or records), specialization, and filtering of observation types by collectors.

Here, filtering is supported by writing observation types to be included as dedicated descriptors to include or exclude given observation types.

19 is a conceptual diagram illustrating an example of a GHS service proposed in this specification.

Two observation characteristics are used to communicate ACOM observations using a predefined format.

2 separate devices so that a client (e.g. PHG, collector) can control a sensor (e.g. PHD, server) that transmits live-data, stored data, or both characteristics are used. A server may be allowed to refuse to initiate RACP procedures as long as live observation is transmitted or enabled. The RACP feature supports predefined general RACP procedures.

The characteristics of a GHS feature optionally report the types of observations supported by the sensor and the set of specializations supported. Both items consist of the IEEE 11073-10101 term code set.

Next, Device Information Service (DIS) 1.2 extends the set of supported characteristics to Unique Device Identification (UDI) characteristics. 20 is a conceptual diagram illustrating an example of a DIS proposed in this specification.

The essential attributes of the GHS are the system identifier, manufacturer and model number. This matches the required attributes of ACOM device information.

Next, STS (Simple Time Service) is a new GATT service that can be used in GHS sensors that support time, and is designed to be reused in other profiles. 21 is a conceptual diagram illustrating an example of a general time service proposed in this specification.

The STS contains one property that reports the current time of the sensor's clock. This property also reports the status and capabilities of the clock. The current time field uses the same structure used for timestamps of observations.

This property supports reading, indicating, and writing (optionally, if the server allows the client to set the clock). A client can use a write operation to set the sensor's current time.

When reconnecting to the bonded client, the sensor sends an indication with the current time to properly understand the timestamps of all observations as the first data transmission.

Next, BAS (Battery Service) 1.1 is used by the server to communicate battery and power status to the client. 22 is a conceptual diagram illustrating an example of the BAS proposed in this specification.

Next, we look at User Data Service (UDS) 1.1.

A user data service allows a user to maintain user-related data, such as name, handedness, gender, date of birth, etc., on a server and exposes it to connected clients using a consent procedure. UDS is designed to be used in conjunction with other services in the sports and fitness or healthcare domains. GHS sensors and collectors may include UDS support.

There is a discussion that there is a problem in terms of trusting the user's identity and usability. If the sensor supports it, the collector MUST support getting all data from all users, but in BLS/BLP 1.1 both are optional. This means that a GHS sensor will work with a client that does not support GHS and vice versa, but in a situation where a GHS sensor with UDS has a first client that supports UDS and a second client that is used by one (human) user, the client If the client does not support UDS, this second client cannot access user data associated with the user through UDS.

Sensor devices may deploy advanced mechanisms to establish a high degree of confidence in user identity, such as fingerprint readers or other biometric technologies, but the use of these technologies does not affect the use of UDS.

Next, we look at advertising data transmission, connection establishment, and data exchange in GHS.

Advertising data used for GHS in undirected advertising includes the following:

<<GHS Service UUID>> <<Main device specialization - 4 bytes>> <<GHS required security level - 1 byte>> <<User IDs with data pending - 1 byte / user>>

Next, we look at RCS (and BMS) 1.0.

23 is a conceptual diagram illustrating an example of an RCS proposed in this specification.

The Reconnection Setup Service (RCS) and Reconnection Setup Profile (RCP) together with the Bond Management Service (BMS) allow the GATT client to manage the connection parameters and bonds of the GATT Server. For GHS, the following features are being considered:

- Enable disconnect: The GHS collector allows the sensor to disconnect immediately after sending all data.

- Ready for disconnect: The GHS sensor indicates that it is ready to transmit data to the collector.

These features allow a more synchronous implementation of GHS.

- Enable disconnection: The GHS collector first uses the RACP procedure to retrieve stored observations. After this procedure, the GHS collector activates disconnection and re-enables indications and notifications. And, the GHS receiver receives pending temporary storage or real-time observations from the sensors. When the sensor finishes sending these data, it can immediately disconnect and request disconnection.

- Ready to Disconnect: When there is no more live data to transmit, the GHS sensor indicating that the connection is ready to be disconnected allows the collector to disable indications and notifications for live data and disconnect.

In order for these functions to be supported, the characteristics shown in FIG. 23 must be supported.

As used herein, the term “unit” (eg, a controller) may refer to a unit including one or a combination of two or more of, for example, hardware, software, or firmware. “Unit” may be used interchangeably with terms such as, for example, unit, logic, logical block, component, or circuit. A "unit" may be a minimum unit of an integrally constituted part or a part thereof. A “unit” may be a minimal unit or part thereof that performs one or more functions. A “unit” may be implemented mechanically or electronically. For example, a "unit" may be any known or future developed application-specific integrated circuit (ASIC) chip, field-programmable gate arrays (FPGAs), or programmable-logic device that performs certain operations. may contain at least one.

At least some of the devices (eg, modules or functions thereof) or methods (eg, operations) according to various embodiments may be stored on computer-readable storage media in the form of, for example, program modules. It can be implemented as a command stored in . When the command is executed by a processor, the one or more processors may perform a function corresponding to the command. The computer-readable storage medium may be, for example, a memory.

Computer-readable storage media / computer-readable recording media include hard disks, floppy disks, magnetic media (eg magnetic tape), optical media (eg CD-ROM (compact) disc read only memory), digital versatile disc (DVD), magneto-optical media (e.g. floptical disk), hardware devices (e.g. read only memory (ROM), random access memory), or flash memory, etc. In addition, program commands may include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter, etc. The hardware devices described above may be configured to act as one or more software modules to perform the operations of various embodiments, and vice versa.

A module or program module according to various embodiments may include at least one or more of the above-described components, some may be omitted, or additional other components may be included. Operations performed by modules, program modules, or other components according to various embodiments may be executed in a sequential, parallel, repetitive, or heuristic manner. Also, some actions may be performed in a different order, omitted, or other actions may be added.

As used herein, the term "a" is defined as one or more than one. Also, the use of introductory phrases such as “at least one” and “one or more” in a claim means that the same claim includes introductory phrases such as “at least one” and “one or more” and ambiguous phrases such as “an”. If any, be construed to mean that the introduction of another claim element by the ambiguous phrase "an" limits any particular claim containing the so-introduced claim element to an invention containing only one such element. It shouldn't be.

Unless otherwise specified, terms such as "first" and "second" are used to arbitrarily distinguish the elements they describe. Thus, these terms are not necessarily intended to indicate a temporal or other order of priority of such elements, and the mere fact that certain measures are recited in mutually different claims does not indicate that a combination of these measures cannot be used to advantage. . Accordingly, these terms are not necessarily intended to indicate a temporal or other priority of such elements. The mere fact that certain measures are cited in different claims does not indicate that a combination of these measures cannot be useful.

Arrangements of components to achieve the same function are effectively "related" so that the desired function is achieved. Thus, any two components that are combined to achieve a particular functionality may be considered "related" to each other such that the desired function is achieved, regardless of structure or intervening components. Similarly, two components so associated can be considered "operably connected" or "operably coupled" to each other to achieve a desired function.

Further, those skilled in the art will recognize that the boundaries between the functionality of the foregoing operations are exemplary only. A plurality of actions may be combined into a single action, a single action may be distributed into additional actions, and the actions may be executed at least partially overlapping in time. Also, alternative embodiments may include multiple instances of a particular operation, and the order of operations may be changed in various other embodiments. However, other modifications, variations and alternatives are also possible. Accordingly, the detailed description and drawings are to be regarded in an illustrative rather than a limiting sense.

The phrase “may be X” indicates that condition X can be met. This phrase also indicates that condition X may not be satisfied. For example, a reference to a system that contains a specific component should also include a scenario where the system does not contain that specific component. For example, a reference to a method that includes a specific action must also include scenarios in which the method does not include that specific component. But to take another example, a reference to a system configured to perform a specific action should also include a scenario in which the system is not configured to perform the specific action.

The terms "comprising", "having", "consisting of", "consisting of" and "consisting essentially of" are used interchangeably. For example, any method may include at least the operations included in the drawings and/or specifications, and may include only the operations included in the drawings and/or specifications.

It should be understood that the boundaries between logical blocks are merely illustrative, and that alternative embodiments may merge logical blocks or circuit elements or impose alternative decompositions of functionality on various logical blocks or circuit elements. will recognize that there is Accordingly, it should be understood that the architecture shown herein is merely illustrative, and in fact many other architectures that achieve the same functionality may be implemented.

Also, for example, in one embodiment, the illustrated examples may be implemented on a single integrated circuit or as circuitry located within the same device. Alternatively, the above examples may be implemented as any number of discrete integrated circuits or discrete devices interconnected with each other in any suitable manner, and other alterations, modifications, variations and alternatives are also possible. Accordingly, the specification and drawings are to be regarded in an illustrative rather than restrictive sense.

Also, for example, any of the above examples or portions thereof may be implemented as a software or code representation of a physical circuit or a logical representation translatable to a physical circuit, such as any suitable type of hardware description language.

In addition, this specification is not limited to physical devices or units implemented with non-programmable hardware, but is generally referred to herein as a 'computer system' such as mainframes, mini computers, servers, workstations, personal computers, notepads, etc. Programmable devices capable of performing desired device functions by operating in accordance with appropriate program code, such as personal digital assistants (PDAs), electronic games, automobiles and other embedded systems, mobile phones and various other wireless devices. Or it can be applied to units as well.

A system, apparatus or device referred to in this specification includes at least one hardware component.

Connections as described herein may be any type of connection suitable for transmitting a signal from or to a respective node, unit or device via an intermediate device, for example. Thus, unless implicitly or otherwise stated, a connection may be, for example, a direct connection or an indirect connection. A connection may be described or described with reference to a single connection, multiple connections, unidirectional connections, or bidirectional connections. However, different embodiments may vary the implementation of connectivity. For example, separate unidirectional connections can be used instead of bidirectional connections, and vice versa. Also, multiple connections may be replaced with a single connection that transmits a plurality of signals sequentially or in a time multiplexed manner. Likewise, a single connection carrying multiple signals can be broken into multiple connections carrying subsets of these signals. Thus, many options exist for transmitting signals.

It should be understood that the boundaries between logical blocks are merely illustrative, and that alternative embodiments may merge logical blocks or circuit elements or impose alternative decompositions of functionality on various logical blocks or circuit elements. will recognize that there is Accordingly, it should be understood that the architecture shown herein is merely illustrative, and in fact many other architectures that achieve the same functionality may be implemented.

In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word 'comprising' does not exclude the presence of any of the recited elements or acts in a claim.

In the above, a preferred embodiment of the technology of this specification has been described with reference to the accompanying drawings. Here, the terms or words used in this specification and claims should not be construed as being limited to ordinary or dictionary meanings, but should be interpreted as meanings and concepts consistent with the technical spirit of the present specification. The scope of the present specification is not limited to the embodiments disclosed herein, and the present specification may be modified, changed, or improved in various forms within the scope described in the spirit and claims of the present specification.

Claims (1)

In the method for performing the GHS service,
advertising, by the server, for connectable GHS beacons;
adding, by the client, a new device to the profile of the client;
sending, by the client, a first pairing request to the server;
connecting, by the server, a compatible GHS client to the client by confirming pairing with the client;
reading, by the server, characteristics of the server to the client;
setting, by the server, GHS settings; and
sending, by the client, a GHS start to the server.

Images