KR20230097608A - Method for performing exposure notification service in bluetooth and apparatus supporting the same - Google Patents

Abstract

This specification provides methods to prevent the spread of infection of COVID-19.
More specifically, the method performed by the mobile terminal includes receiving, from the wearable device, an advertising message including exposure notification information indicating whether exposure to COVID-19 has occurred; To notify the user that exposure to COVID-19 has occurred in the area when an advertisement message including exposure notification information indicating exposure to COVID-19 has been received at the time of entering an area where the advertisement message can be received outputting an alarm message through an output unit of the mobile terminal through at least one of a visual, auditory, or tactile method; and transmitting a message including exposure notification information indicating exposure to COVID-19 to another mobile terminal on the mesh network through a flooding method or a routing method.

Description

METHOD FOR PERFORMING EXPOSURE NOTIFICATION SERVICE IN BLUETOOTH AND APPARATUS SUPPORTING THE SAME}

The present specification relates to Bluetooth, and more particularly, to a method for performing an exposure notification service in Bluetooth and a device supporting the same.

Bluetooth, one of the technologies underlying IoT, 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. Bluetooth has a guard band of 2 MHz below and 3.5 MHz above in this band, uses a total of 79 channels by setting the bandwidth of each channel to 1 MHz, 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 Bluetooth technology inherited from Bluetooth 1.0 using Basic Rate and Bluetooth technology using 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 5 increases this broadcast capacity eightfold, 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.

The present specification aims to prevent the spread of COVID-19 by detecting and notifying individuals of potential exposure by providing an exposure notification service in Bluetooth communication.

This specification provides methods to prevent the spread of infection of COVID-19.

More specifically, the method performed by the mobile terminal includes receiving, from the wearable device, an advertising message including exposure notification information indicating whether exposure to COVID-19 has occurred; To notify the user that exposure to COVID-19 has occurred in the area when an advertisement message including exposure notification information indicating exposure to COVID-19 has been received at the time of entering an area where the advertisement message can be received outputting an alarm message through an output unit of the mobile terminal through at least one of a visual, auditory, or tactile method; and transmitting a message including exposure notification information indicating exposure to COVID-19 to another mobile terminal on the mesh network through a flooding method or a routing method.

The present specification has the effect of preventing the spread of COVID-19 by detecting and notifying individuals of potential exposure by providing an exposure notification service in Bluetooth communication.

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 is a diagram showing an example of an advertisement payload format proposed in this specification.
13 is a diagram illustrating an example of an ENS-related broadcasting flow proposed in this specification.
14 is a diagram illustrating an example of an ENS-related scanning flow proposed in the present specification.
15 shows an example of a flowchart between an ENS-related server and a client proposed in this specification.
16 shows an example of a flowchart between an ENS-related server and a client proposed in this specification.
17 shows an example of a flowchart between an ENS-related server and a client proposed in this specification.
18 is a flowchart illustrating an example of a method of removing Client ENS proposed in this specification.
19 is a flowchart illustrating an example of a procedure for adding a Client ENS proposed in this specification.
20 is a diagram showing an example of a flow chart between a server and clients proposed in this specification.
21 is a flowchart illustrating an example of an ENS-related procedure proposed in this specification.
22 is a flowchart illustrating an example of a procedure between a server and a client proposed in this specification.
23 is a flowchart showing an example of a method for confirming whether or not COVID-19 is infected through the W-ENS 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 three advertising channels (channels 31, 38, and 39), and then 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.

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 obtain 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.

edge A node is usually powered by a battery, and can be interacted with or periodically woken up from a normally sleep state.

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 mesh network of the floating method is a dynamic network, and in the mesh network of the floating method, a device may be able to 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).

Wearable ENS (Exposure Notification Service, W-ENS)

Exposure notifications can prevent the spread of the pathogen that causes COVID-19, the coronavirus, by warning participants of possible exposure to people they have recently come into contact with. The exposure notification service is a means to implement exposure notification, and provides a mechanism for proximity detection and data exchange of nearby smartphones using Bluetooth Low Energy wireless technology. Namely, exposure notification services (or systems) (ENS) are being deployed globally to help slow and potentially contain SARS-CoV-2 outbreaks by detecting and notifying individuals of potential exposure. Most of these systems rely on individuals owning and carrying compatible client devices such as smartphones. However, depending on the country, a significant portion of the world's population does not own compatible client devices and is unable to participate in ENS. It affects certain groups in society, such as children and the elderly. Similarly, people who have compatible clients that are not always portable or accessible (e.g. classroom sessions or team sports) may not be able to participate during that time. These systems only have a significant impact on slowing outbreaks if a majority of the population has access and people use the systems continuously. It defines a standardized way for non-internet-connected wearable devices to operate in a complementary manner with one or more distributed client-based ENSs, allowing a significant number of additional individuals to participate in the ENS. The methods defined here apply to the containment of various infections, including SARS-CoV-2.

The Transport Discovery Service (TDS) allows devices using Bluetooth LE radio technology to expose services available on transports other than Bluetooth LE. The term 'transport' used in this document refers to a communication technology that can be used to transfer data between a server and a client. When used in conjunction with higher-level documents (e.g. documents that reference and use TDS), the information provided by this service facilitates the discovery (or discovery) and exploitation of transmissions not defined by BR/EDR or Bluetooth SIG. can be used to When conformance to this service is required, all capabilities indicated as mandatory for this service are supported in the specified way (process-required). This applies to all optional and conditional capabilities for which support is indicated. This service does not depend on other services.

This document is compatible with any Bluetooth core spec. including the GATT (Generic Attribute Profile) and the Bluetooth LE controller part of the Bluetooth Core Spec.

A brief summary of the terms used in the exposure notification service.

- Exposure notification service - Bluetooth Low Energy service for detecting device proximity.

- Temporary exposure key - A key generated every 24 hours to protect personal information.

- Diagnosis key - A subset of temporary exposure keys that are uploaded when a device owner is diagnosed positive for coronavirus.

- rolling proximity identifier - a privacy identifier derived from a temporary exposure key and transmitted as a broadcast in a Bluetooth payload. The identifier changes approximately every 15 minutes to prevent wireless tracking of the device.

- Associated Encrypted Metadata (AEM) - privacy preserving encrypted metadata used to pass protocol versioning and transmit (Tx) power for better distance approximation. The associated encrypted metadata is changed at the same cadence as the rolling proximity identifier approximately every 15 minutes to prevent wireless tracking of the device.

Hereinafter, advertising and scanning operations for ENS in Bluetooth are briefly described.

Devices broadcast and retrieve exposure notification services through 16-bit service UUIDs (Universally Unique Identifiers). Service data types using this service UUID must contain a rolling proximity identifier and associated encrypted metadata. And, both change periodically.

Advertising Payload

The exposure notification service payload must be aligned as shown in FIG. 12 and does not include other data types.

12 is a diagram showing an example of an advertisement payload format proposed in this specification.

Referring to FIG. 12, the advertisement payload 1200 includes a flag field 1210 including length, type, and flag, a complete 16-bit service UUID field 1220, and a service data-16-bit UUID field 1230. includes That is, the exposure notification service includes the following four sections (or fields).

1. Flag section - Bluetooth LE general discoverable mode (bit 1) is set to '1'.

2. Complete 16-bit service UUID section - The UUID may be 0xFD6F, and comes before the service data section.

3. Service Data 16-bit UUID Section - This section has two other sections in the payload.

a. 16-byte rolling proximity identifier.

b. 4 bytes of associated cryptographic metadata (LSB first) containing:

i) Byte 0 - versioning.

- Bits 7:6 - Major version (01).

- Bits 5:4 - Minor version (00).

- Bits 3:0 - reserved for future use.

ii) Byte 1 - transmit power level.

- The measured radiated transmit power of the Bluetooth advertising packet, used to improve the distance approximation. This section (or field) ranges from -127 to +127 dBm.

iii) Byte 2 - reserved for future use.

iv) Byte 3 - reserved for future use.

broadcasting behavior

- During Bluetooth broadcasts, advertisements are non-connectable undirected of type ADV_NONCONN_IND.

- Advertiser address type is Random Non-Resolvable.

- On platforms that support Bluetooth random private addresses with random rotation timeout intervals, the advertiser address rotation period is a random value of 10 minutes or more and less than 20 minutes.

- Advertiser addresses, rolling proximity identifiers and related encrypted metadata are changed synchronously so that they cannot be linked.

- Where the hardware allows, a separate Bluetooth broadcast instance should be used to provide reliability and flexibility in choosing the optimal interval.

- The broadcasting interval can be changed, but it is currently recommended at 200-270 milliseconds.

13 is a diagram illustrating an example of an ENS-related broadcasting flow proposed in this specification.

That is, FIG. 13 shows an example of a broadcasting flow between devices.

Referring to FIG. 13 , the first entity sets and transmits an EN state setting request message (eg, ENStateSetRequest) to 'True' to the second entity. The second entity then requests user permission to enable exposure notification. Then, the second entity generates a temporary_exposed_key. Thereafter, the second entity derives (derives) a rolling proximity identifier (Temporary_Exposure_Key, etc.). Then, the second entity receives a rolling proximity identifier and associated encrypted metadata from the third entity. Then, the second entity transmits a Bluetooth broadcast (exposure notification service UUID, rolling proximity identifier, associated encrypted metadata) to the fourth entity. Then, the fourth entity stores the rolling proximity identifier and associated encrypted metadata. After 15 minutes have elapsed, the second entity derives a rolling proximity identifier (Temporary_Exposure_Key, etc.) to the third entity. And, the second entity receives a rolling proximity identifier and associated encrypted metadata from the third entity. Then, the second entity transmits a Bluetooth broadcast (exposure notification service UUID, rolling proximity identifier, associated encrypted metadata) to the fourth entity. Then, the fourth entity stores the rolling proximity identifier and associated encrypted metadata. After 24 hours have elapsed, the second entity generates a temporary_exposed_key and associated encrypted metadata.

In FIG. 13, the first entity may be an application local, the second entity may be a framework/Bluetooth local, the third entity may be an encryption local, the fourth entity may be a framework/Bluetooth remote, The fifth entity may be an encryption remote. However, the terms of the first entity to the fifth entity are examples, and may be changed according to the contents described in this specification, of course.

Scanning Behavior

- Discovered exposure notification service advertisements must be maintained on the device.

- Scan results are captured with timestamp and RSSI for each broadcast.

- The scanning interval and window must have sufficient coverage to discover nearby exposure notification service advertisements within 5 minutes.

- The scanning strategy that works best is opportunistic (using an existing wake-up and search window) and uses a minimum periodic sampling every 5 minutes.

Scan Power Considerations

- The platform running the exposure notification service must be designed to account for the large number of broadcasters in public places, and the random non-resolvable address and rolling proximity identifier need to be replaced frequently.

- If supported by the hardware and operating system, the Bluetooth controller duplicates the filter, and other hardware filters are used to prevent excessive power consumption.

Scanning Flow

14 is a diagram illustrating an example of an ENS-related scanning flow proposed in the present specification.

That is, FIG. 14 shows an example of a device scanning operation.

The first entity, the second entity, the third entity, the fourth entity, and the fifth entity described in FIG. 14 mean different things from the entities represented in FIG. 13, and it is clear that the same terms are used for convenience of description. .

Referring to FIG. 14 , the first entity receives an EN state setting request message (ENStateSetRequest) set to 'True' from the second entity. Then, the first entity requests user permission to enable exposure notification. Then, the first entity scans the temporary exposure service UUID. Thereafter, the first entity receives a Bluetooth broadcast (exposure notification service UUID, rolling proximity identifier, associated encrypted metadata) from the third entity. Then, the first entity stores the rolling proximity identifier and associated encrypted metadata. Then, the first entity receives a Bluetooth broadcast (exposure notification service UUID, rolling proximity identifier, associated encrypted metadata) from the third entity. Then, the first entity stores the rolling proximity identifier and associated encrypted metadata. And, the second entity performs Periodic Diagnosis_Key Fetch. Then, the second entity receives Diagnosis_Keys from the fourth entity. Then, the first entity receives ENExposureDetectionSession (List of Diagnosis_Keys) from the second entity. Then, the first entity resolves Diagnosis_Keys for all rolling proximity identifiers. Thereafter, the first entity transmits Resolve (RPI, Diagnosis_Key) to the fifth entity. Thereafter, the first entity receives Match/No-Match from the fifth entity. The first entity then runs an algorithm that will evaluate the risk based on the duration of exposure. Then, the first entity transmits ENExposureDetectionSummary (number of matches, most recent date of contact) to the second entity. Then, the first entity receives ENExposureDetectionSession (get info) from the second entity. Then, the first entity may notify the user about the exposure. Then, the first entity transmits ENExposureinfo (Day, duration, attenuation) to the second entity. Thereafter, the second entity may close a confirmed diagnosis.

In FIG. 14 , the first entity may be a framework/Bluetooth remote, the second entity may be an application remote, the third entity may be a framework/Bluetooth local, and the fourth entity may be a cloud (server). , the fifth entity may be an encryption remote, and the sixth entity may be an encryption local. However, the terms of the first entity to the sixth entity are examples, and may be changed according to the contents described in this specification, of course.

Privacy

Maintaining user privacy is an essential requirement in ENS Spec., and the protocol maintains privacy in the following way.

- Exposure notification Bluetooth spec. does not use location for proximity detection. That is, it strictly uses Bluetooth beaconing to detect proximity.

- A user's rolling proximity identifier changes every 15 minutes on average, and a temporary exposure key is required to interconnect with a contact. This action reduces the risk of privacy loss from broadcasting identifiers.

- Proximity identifiers obtained from other devices are processed only by the device.

- Users decide whether or not to contribute to exposure notifications.

- If diagnosed with COVID-19, the user must provide the user's consent to share the diagnosis key with the server.

- Users have transparency for participation in exposure notifications.

Continuing from the foregoing, the requirements represent a minimum set of requirements for a GATT server. Other GATT sub-procedures may be used if both client and server are supported. Table 2 shows additional GATT sub-procedure requirements that are necessary beyond those required by all GATT servers.

In Table 2, C.1 is mandatory if the temporary key list property is exposed, and optional otherwise.

This service works only via Bluetooth LE transmission. This service does not define the following property protocol application error codes not yet defined in CSS (Core Specification Supplement).

All characteristics used in this service are transmitted in LSO (least significant octet first) (i.e. little endian). The identification of LSOs is GATT Spec. Supplement (GSS) or elsewhere in this document. Where formats are described in tables in this document, LSO is the first octet in the top field of the table, and MSO is the last octet in the bottom field of the table.

The server becomes a GAP peripheral or GAP broadcaster. If the server is a GAP peripheral, the following requirements apply.

- This service is instantiated as ≪Primary Service≫.

- Only one instance of this service is exposed on the device.

- The service UUID (Universally Unique Identifier) is set to ≪Wearable Exposure Notification Service≫.

An advertisement packet may contain multiple AD types according to space availability criteria as allowed by the Bluetooth Core Spec. W-ENS service data is advertised when a server has established a relationship with a connectable or trusted client and new data is available. W-ENS service data uses Service Data-16 bit UUID AD type, and the format is described in Table 3.

UUID means a unique ID that distinguishes each service provided by a device in Bluetooth.

Up to 13 UUIDs (Universally Unique Identifiers) can be listed in a standard advertisement packet depending on whether there are additional AD types in the advertisement packet. However, the Bluetooth Core Spec. In v5.0 and higher, additional values may be supported by using the extended advertising feature. The length field is included in W-ENS service data. This field contains the length of 1 octet of W-ENS service data not including the length of the length field. For example, if the W-ENS service data contains only a single ENS service UUID, the length value (and thus the minimum possible length value) is 0x06. Service data - 16 bit UUID AD type code field is included in W-ENS service data. This field contains a 1-octet value defined in GAP (Generic Access Profile). A 16-bit service UUID field is included in W-ENS service data. This field contains the 2 octet W-ENS service UUID value. The ENS flag field is included in W-ENS service data. This field contains a 1-octet value indicating whether the device is connectable and other characteristics. The values of this field are defined in Table 4. Table 4 shows an example of the ENS flag field.

The full UUID list in AD bit indicates whether the Supported ENS Services UUIDs field contains a full or incomplete list of UUIDs. If the list is incomplete, the AD bit is set to 0, otherwise it is set to 1. In case the list is incomplete, the full list of UUIDs can be found in the GATT database. This can be used when there is insufficient space in the advertising packet for the entire content.

The Trusted Connection bit indicates whether the server supports the ability to form a trusted connection with a client, and if so, the current state. If the bit is set to '0b00', the server does not support the ability to form a trusted connection with the client. If the bit is set to '0b01', the server supports the ability to form a trusted connection with a client, and is currently in a state where it can accept connections. If the bit is set to '0b10', the server has established a trusted connection and has new data available to the trusted client. If the bit is set to '0b11', the server has established a trusted connection, but no new data is available since the last connection to the trusted client.

The supported ENS service UUID field is included in W-ENS service data. This field contains a list of 16-bit UUIDs representing supported exposure notification systems. This list contains at least one 16-bit UUID. For example, the Apple and Google exposure notification systems specify the 16-bit UUID 0xFD6F. Table 5 below shows when W-ENS service data can be advertised. The bits of the ENS flag fields are used to indicate the context of the data. Table 5 shows an example of an advertisement operation for W-ENS service data.

If the server reaches the maximum number of bonds and the client attempts to bond, the Security Manager pairing failure message returns the error code Pairing Not Supported . It is an implementation choice whether bonding with the new client will delete all old records and temporary keys or whether the new client will have access to all old records and temporary keys.

The format of advertisement data specific to each exposure notification service is specified by each exposure notification service and is outside the scope of the standard. It is advertised when the server is in a mode set by the client and advertises ENS-specific advertising data.

Once bonded or connected to a trusted client, an ENS is selected using the selected ENS descriptor, certain settings are set, and the selected ENS is started. The server advertises using the advertisement packet format and interval defined by ENS, and scans advertisement packets of the same ENS type using the scan interval and scan window defined by ENS. If specific advertisement and scan parameters are not defined for the server by the ENS, the same values specified in the ENS for the client should be used.

ENS systems vary, but generally follow a protocol similar to the following.

- The server generates a Rolling Proximity Identifier (RPI) that changes several times an hour from an ephemeral key that rotates approximately once a day.

- The server advertises the RPI and other data in the format and interval specified in the ENS.

- The server records the received RPI along with the time, Received Signal Strength Indication (RSSI) and other data using the scan interval and scan window specified in the ENS.

For example, when an Apple/Google ENS is selected and started, the server advertises and scans according to the parameters specified in the Apple/Google documentation.

For a server that supports multiple ENSs, while advertising, the server advertises the RPI and stores the selected ENS while scanning, and the server stores the selected ENS while logging received RPIs.

Hereinafter, requirements related to GATT characteristics and descriptors used in the W-ENS service are defined. Unless otherwise specified, only one instance of each property in Table 8 is allowed within this service.

If a characteristic can be indicated or notified, the client characteristic setting descriptor MUST be included in that characteristic as required by the Core Spec. Characteristic requirements for this service are listed in Table 6.

In Table 6, C.1 is mandatory if more than one exposure notification system is supported, except otherwise. Attributes not listed as required or optional are excluded from service in this version.

ENS record

The ENS record 1 property is a variable length structure used to transmit the first of two parts that together form an exposure notification data record. The existence of optional fields depends on the contents of the flag field. The structure of this property is defined in Table 7.

The bits of the Flags field are defined in Table 8.

The structure of the sequence number field is defined in Table 9.

The structure of the RSSI field is defined in Table 10.

The structure of the Time Offset field (designating the time difference from the Time Stamp) is defined in Table 11.

The ENS record 2 property is a variable length structure used to transmit the second part of an exposure notification record. The presence of optional fields depends on the content of the flags field. The structure of this property is defined in Table 12.

The bits of the Flags field are defined in Table 13.

The ENS feature feature contains information about supported features related to exposure notification capabilities. The structure of this property is defined in Table 14.

The bits of the ENS feature field are defined in Table 15.

The supported exposure notification systems property indicates the exposure notification systems supported by the server. The structure of this property is defined in Table 16.

The structure of this descriptor follows the same format as the supported exposure notification system properties defined in Table 16.

This version of the service allows only one exposure notification system to be used at a time, so only one bit can be set at a time. The client is responsible for choosing which supported system to use, and as the server roams the client may change the notification system in use. The ENS settings property represents device settings specific to the currently selected exposure notification system. The structure of this property is defined in Table 17.

The ENS clock characteristic represents the device's current time in seconds. If a clock value is set, it represents absolute time in seconds. If no clock value is set, it represents a relative time in seconds. The structure of this property is defined in Table 18.

movement

Unset clock increases from 0x0000. Clocks that cannot be set use relative time. For this click, the client reads the value to set the time reference to the counter. For these clocks, the client reads the current value of the clock so that it can map the clock to local time. Clocks that can be set use absolute time (set once) and follow the format for the epoch (e.g. 12:00 AM, January 1, 2020 UTC). For these clocks, the client reads the clock's current value and updates it to the current time using the device time service. Upon reset (or reset) or loss of power, the clock resets to a value of 0x0000. The structure of this descriptor is defined in Table 19.

The structure of this descriptor is defined in Table 20.

The temporary key list property represents a 32-bit temporary key list provided by the client to be used by the server to generate the RPI. The structure of this property is defined in Table 21.

A record access control point is used with this service.

For this service to work, the profile or other application using this service must ensure that the client sets record access control point (RAP) properties on the instructions (ie, via the client property setting descriptor). The client must write to the record access control point to execute the desired procedure on the server.

record definition

Within the context of this service, a record (also referred to as an ENS record) consists of an ENS record 1 property, which may or may not be followed by a corresponding ENS record 2 property. If an ENS record 1 attribute is followed by an ENS record 2 attribute, the segmented record bit in the flags field of the ENS record 1 attribute is set to '1', and the value of the sequence number field between the two attributes must be the same. A device implementing a server MUST persistently store ENS record data so that it can be retrieved by authorized clients.

RACP procedural requirements

Table 22 and Table 23 show the requirements for Record Access Control Point (RACP) procedures (op codes, operators, and operands) in the context of this service.

In Table 22, C.1 If this operator is supported, this operand is required for this operator. Support of a given operand for one opcode and operator combination does not support that operand for another opcode and operator combination. Support for a given operator for one op code does not imply support for that operator for another op code. When filter types and filter parameters are used, the byte order of the operands is specified. Table 23 is a table showing an example of RACP procedure requirement-response.

Table 24 shows the relationship between RACP operators and operands.

When using the 'within range' operator, the minimum value of the range must be less than or equal to the maximum value of the range, regardless of the filter type used for the operand.

The following table shows the supported filter types applied to the three operators listed in Table 22 (i.e. less than or equal to, greater than or equal to, and within range). Within the operand, the filter type specifies the field of the ENS record 1 property on which filtering is based. The RACP operands that enable user-specified filtering of ENS data records are shown in Table 25.

RACP Operation Description

The record access control point is used to control the announcement of ENS data. The procedure writes to this property, which contains an action code specifying the action (see Tables 22 and 23) and valid operators and operands (see Table 24) within the context of that action code. triggered by In the case of multi-bonds, the processing of record access control points must be consistent across all bonds. That is, there is a single database shared by all clients.

Since the operand value is defined per service, when RACP is used with this service, the filter type field is defined to enable flexible filtering based on other criteria (eg, sequence number or user facing time).

Some procedural operators (ie less than or equal to, greater than or equal to, and within range) require a filter type as part of an operand. It is used to specify the fields in the ENS record 1 property that are used to perform filtering.

If used, the filter type field always precedes any applicable filter parameters within the operand. For example, when used with the 'in range' operator, the operand has the form <filter type> <min> <max> where the filter type is the least significant octet of the operand. For a list of valid filter type values, refer to Table 25.

When using a sequence number filter type, the format of the operand is the sequence number filter type value followed by a pair of applicable sequence number values or operator-dependent values.

When using the User Facing Time Filter Type, the format of the operand is either the applicable User Facing Time (sum of reference time and time offset) or the User Facing Time Filter Type value followed by an operator-dependent value pair.

report number of stored records procedure

When the report number of stored record operation codes is written to the record access control point, the server calculates and responds with the number of records in UINT 16 format based on filter criteria, operator and operand values. Tables for operand requirements when used with certain operators are referenced, and in some cases no operands are used. The number of records reported in the response is calculated based on the current state of the database and may change between connections or after records are cleared. The response is indicated using the number of records stored response action code. If the operation results in an error condition, this is indicated using the response code action code and the appropriate response code value in the operand for the error condition.

If the server does not find a record that matches the request's filter criteria, the server SHOULD direct the record access control point with the number of record response action codes stored and the operands set to 0x0000.

If an error condition occurs as a result of the operation, this is indicated using the response code operation code and the appropriate response code value in the operand for the error condition.

Stored Record Deletion Procedure

If the stored record deletion operation code is recorded in the record access control point, the server can delete the specified ENS record based on the values of operators and operands. Deleting a record is considered permanently deleting the record from the ENS record database. See the table for operand requirements when used with certain operators, and in some cases no operands are used. Due to the sensitivity of the data, it is acknowledged that the server only allows data to be deleted by certain clients.

The server SHOULD indicate this property with a response code value of success if the record was successfully deleted from the ENS record database.

If the server does not find records that match the request's filter criteria, the server directs the record access control point with the values of the response code action code and response code in the operand set to No Records Found .

If an operation results in an error condition, this will be indicated using the response code action code and the appropriate response code value in the operand for the error condition.

Stored Records Reporting Procedure

When the report stored record operation code is written to the record access control point, the server SHOULD advertise the set of stored ENS records selected based on filter criteria specified in the operators and operands. When used with certain operators, see the table for operand requirements, in which case no operands are used. The meaning of record transfer is not 'move' of a record, but 'copy' of a record.

The transmission of an ENS record includes notification of the ENS record 1 property and, depending on the segmented record bit value of the ENS record 1 property, may include the ENS record 2 property. When advertising segmented records, notifications for ENS record 1 properties must follow notifications for ENS record 2 properties.

The Time Offset field MUST be included in the first transmitted ENS record 1 attribute, and MUST also be included in subsequent records whenever the value of the Time Offset field changes. Otherwise, the time offset field is optional.

If a new ENS record is available during the record transfer (i.e. after the report stored record procedure has started), the server MAY include this new record in the record transfer. Profiles using this service are required to allow for the possibility of receiving one more record than the customer expected.

When all data records for a given request have been notified by the server, the server indicates the record access control point with the response code action code and response code values in the operand set to Success.

If the server does not find records that match the request's filter criteria, the server directs the record access control point with the response code action code and response code values in the operand set to No Records Found .

If an operation results in an error condition, this is indicated using the response code operation code and the appropriate response code value in the operand for the error condition.

If, for any reason, the server must stop sending data before completion, the server directs the record access control point with the values of the response code, action code, and response code in the operand set to Procedure not completed.

Abort Operation Procedure

When an abort action op code is written to the record access control point, the server MUST do its best to abort the ongoing RACP procedure and stop sending further data.

When all RACP procedures are suspended, the server shall indicate the record access control point using the response code operation code and response code values in the operand set to Success.

If an operation results in an error condition, this is indicated using the response code operation code and the appropriate response code value in the operand for the error condition.

General Error Handling Procedure

In addition to error handling procedures specified by specific action codes, the following applies.

If the operation code (op code) recorded in the record access control point attribute is not supported by the server, the server directs the record access control point with the response code op code and response code values in the operand set to 'Op Code Not Supported'. Should be.

If the operator recorded in the record access control point property is invalid, the server shall indicate the record access control point with the response code op code and response code values in the operand set to 'Invalid Operator'.

If the operator recorded in the record access control point property is not supported by the server, the server SHOULD indicate the record access control point with the response code op code and response code values in the operand set to 'Operator Not Supported'.

If the operand recorded in the record access control point property is invalid, the server shall indicate the record access control point with the response code op code and response code values in the operand set to 'Invalid Operator'.

If the filter type in the operand recorded in the record access control point property is not supported by the server, the server shall indicate the record access control point with the response code op code and response code values in the operand set to 'Operand Not Supported'.

If the server is unable to complete the procedure for any reason not specified here, the server SHOULD direct the record access control point with the response code op code and response code values in the operand set to 'Procedure not completed'.

If a request with an op code other than an abort operation is logged to the record access control point while the server is performing a previously triggered RACP operation (i.e., due to an invalid client operation), the server returns 'Procedure Already In Progress'. Returns the error response set to the set property protocol application error code.

If the Op Code written to the Record Access Control Point attribute requests record notification and the Client Characteristic Configuration Descriptor is not set for notification, the server returns an Attribute Protocol Application Error Code set to 'Client Characteristic Configuration Descriptor Improperly Configured'. return an error response with an error code).

timeout procedure

In the context of the record access control point characteristic, a timeout procedure is initiated upon successful completion of a write to the RACP characteristic. When the corresponding procedure is completed, the server indicates the RACP characteristic along with the Op code set as 'Response Code'.

A RACP procedure may include a number of characteristic notifications followed by a RACP characteristic indication. If an acknowledgment is not received within the ATT transaction timeout defined as 30 seconds when the server sends an indication of the RACP feature, the response is considered timed out. When a timeout occurs, the server stops sending further instructions and notifications related to the operation, and considers the procedure to have failed.

The server does not perform exposure or risk calculations, and sends the requested data record to the client for processing by the client. The server may perform data pre-processing to minimize the storage or transmission of redundant information when permitted by ENS. To speed up data transmission, the server transmits data using a minimum ATT_MTU of TBD (to be determined) bytes. If the server is supported by the client, the Core Spec. You can also use the 2Mbps PHY feature of (v4.2 or later). The server also, if supported by the client, Core Spec. (v? or higher) data length extension features can be used. Additional implementation-specific information may be included in the data record, such as temperature or pulse data at the time the RPI is advertised.

The server shall transmit the minimum information required to participate in the selected exposure notification system. Servers MUST take care when providing additional information that the server transmits out of the information defined above. The server must delete data according to the data retention policy of ENS.

Hereinafter, requirements related to additional GATT services that may be useful for ENS applications are defined.

The battery service should be used to enable clients on the server to check battery status.

If the server supports the ability for a time base to be established, the device time service must be used to enable the client to synchronize with the server.

The device information service should be used to enable the client to check common device data on the server, including product manufacturer, model number, serial number, revision information of hardware and firmware.

The Bond Management Service should be used to allow clients to delete connections on servers that do not have a user interface.

Hereinafter, based on the contents examined above, ENS-related client(s) operation, server operation, and operation between Client-Server will be reviewed with reference to related drawings. Of course, the above-mentioned contents, tables, etc. can be applied to the contents to be described later. Steps indicated by dotted lines in FIGS. 21 to 28 may or may not be included in the procedure of each drawing.

15 shows an example of a flowchart between an ENS-related server and a client proposed in this specification.

Referring to FIG. 15 , the server advertises a connectable W-ENS beacon (S1501). Then, the server transmits a connection with a compatible ENS_1 client as client 1 (trusted client) (S1502). Then, the client 1 transmits ENS_1 start to the server (S1503). Then, the server advertises and scans for ENS_1-specific beacons (S1504). And, the server performs ENS_1-specific logging of RPIs (S1505). Then, the server advertises connectable W-ENS beacons (at a low duty cycle) (S1506). Then, the server connects and uploads a new ENS_1 data record to client 1 as long as it is available (S1507). Client 2 (new client) adds a new device to its own profile (S1508). Then, the client 2 transmits a first pairing request to the server (S1509). Then, the server confirms pairing by pressing the shaking/button (S1510). Then, the server connects a compatible ENS_2 client to the client 2 (S1511). Then, the server reads server characteristics to the client 2 (S1512). And, the server sets the ENS_2 setting (S1513). Then, the client 2 transmits ENS_2 start to the server (S1514). And, the server advertises and scans for ENS_1 & ENS_2 specific beacons (S1515). And, the server performs specific logging of ENS_1 & ENS_2 of RPIs (S1516). And, the server advertises the connectable W-ENS beacons (at a low duty cycle) (S1517). Then, the server connects and uploads as many new ENS 1&2 data records as are available to clients 1 and 2 (S1518). And, the server continues until the connection is disconnected (S1519).

16 shows an example of a flowchart between an ENS-related server and a client proposed in this specification.

Referring to FIG. 16, the server advertises a connectable W-ENS beacon (S1601). The client adds a new device to its own profile (S1602). Then, the client transmits a first pairing request to the server (S1603). Then, the server confirms pairing by pressing the shaking/button (S1604). Then, the server connects a compatible ENS client to the client (S1605). Then, the server reads server characteristics to the client (S1606). And, the server sets the ENS setting (S1607). Then, the client transmits ENS start to the server (S1608). Then, the server advertises and scans for ENS-specific beacons (S1609). And, the server performs ENS-specific logging of RPIs (S1610). And, the server advertises the connectable W-ENS beacons (at a low duty cycle) (S1611). Then, the server connects and uploads new ENS data records available to the client (S1612). Then, the client transmits pause/resume to the server (S1613). And, the server continues until the connection is disconnected (S1614).

17 shows an example of a flowchart between an ENS-related server and a client proposed in this specification.

Referring to FIG. 17, the server advertises a connectable W-ENS beacon (S1701). Then, the client transmits a connection request to the server (S1702). And, the server connects to the compatible ENS client as the client (S1703). Then, the server reads server characteristics to the client (S1704). And, the server sets ENS settings (S1705). Then, the client starts ENS (S1706). Then, the server advertises and scans for ENS-specific beacons (S1707). And, the server performs ENS-specific logging of RPIs (S1708). Then, the server advertises connectable W-ENS beacons (at a low duty cycle) (S1709). Then, the server connects and uploads new ENS data records as long as they are available (S1710). Then, the client checks the ENS for exposure through the server RPIs and notifies the exposure status (S1711). Then, the client transmits pause/resume to the server (S1712). And, the server continues until the connection is disconnected (S1713).

18 is a flowchart illustrating an example of a method of removing Client ENS proposed in this specification.

If the subject of the method of FIG. 18 is not a server but a client, the subject of steps S1801 to S1811 below may be a client.

First, the (ENS) server advertises a connectable W-ENS beacon (S1801). And, the server receives a connection request from the ENS Client (S1802). Then, the server connects with a compatible ENS Client (S1803). Then, the server reads server characteristics (S1804). And, the server configures to remove the Client ENS from the server ENS setting (S1805). Then, the server disconnects from the client (S1806). Then, the server performs advertising and scanning of ENS-specific beacons for the remaining set ENS (S1807). And, the server logs about scanned RPIs compatible with all configured ENSs (S1808). Then, the server continues to advertise for connectable W-ENS beacons (at a low duty cycle) (S1809). Then, the server connects and uploads as many new ENS data records as possible (S1810). Then, the server continues the previous steps S1808 and S1809 for all remaining set Client ENSs until it stops (S1811).

19 is a flowchart illustrating an example of a procedure for adding a Client ENS proposed in this specification.

If the subject of the method of FIG. 19 is not a server but a client, the subject of the next step may be a client.

First, the server advertises a connectable W-ENS beacon (S1901). And, the server receives a connection request from an additional ENS Client (S1902). Then, the server connects with an additional compatible ENS Client (S1903). Then, the server reads server features (S1904). And, the server sets to support two or more ENSs in server ENS settings (S1905). Then, the Client starts ENS (S1906). And, the server advertises and scans for ENS-specific beacons compatible with all established ENSs (S1907). And, the server logs about scanned RPIs compatible with all configured ENSs (S1908). Then, the server continues to advertise (at a low duty cycle) the connectable W-ENS beacons (S1909). Then, the server connects and uploads as many new ENS data records as are available in the ENS of the clients and clients (S1910). And, (according to use cases), the client pauses and resumes the server (S1911). Then, the server terminates the connection with the client (S1912). After the disconnection, the server continues steps S1908 and S1909 (S1913). Then, the server continues for all configured ENSs until stopped/removed by an additional Client (S1914). Then, the server continues the previous steps S1908 and S1909 for all remaining configured Client ENSs until it is stopped (S1915).

20 is a diagram showing an example of a flowchart between a server and clients proposed in this specification.

If the subject of the method of FIG. 20 is not a server but a client, the subject of the following steps may be a client.

First, Client 1 (eg Phone), (Wearable) Server and Client 2 (eg Phone) connect and upload a new ENS data record that can be used in the client and the client's ENS (S2001). And, the server advertises and scans for connectable W-ENS beacons (S2002). Then, Client 1 connects to the server and obtains a data record (S2003). Then, Client 1 transmits an HCI_Create_Connection message to the server (S2004). Then, Client 1 receives the HCI_Command_Status message from the server (S2005). Then, ENS data records are uploaded between Client 1 and the server (S2006). Then, Client 2 connects to the server and obtains a data record (S2007). Then, Client 2 transmits an HCI_Create_Connection message to the server (S2008). Then, Client 2 receives HCI_Command_Status (S2009). Then, ENS data is uploaded between Client 2 and the server (S2010).

21 is a flowchart illustrating an example of an ENS-related procedure proposed in this specification.

If the subject of the method of FIG. 21 is not a server but a client, the subject of the following steps may be a client.

First, the server advertises a connectable W-ENS beacon (S2101). Then, the server receives a connection request (S2102). Then, the server connects with a compatible ENS Client (S2103). Then, the server reads server features (S2104). And, the server sets server ENS settings (S2105). Then, the Client starts ENS (S2106). Then, the server advertises and scans for ENS-specific beacons (S2107). And, the server performs ENS-specific logging of the scanned RPIs (S2108). Then, the server continues to advertise for connectable W-ENS beacons (at a low duty cycle) (S2109). Then, the server connects and uploads as many new ENS data records as are available (S2110). Then, (according to use cases), the client pauses and resumes the server (S2111). Then, the server terminates the connection with the client (S2112). And, after the connection termination, the server continues steps S2108 and S2109 (S2113). And, the server continues until stopped by the client (S2114).

22 is a flowchart illustrating an example of a procedure between a server and a client proposed in this specification.

First, the Client (eg Phone) and the (Wearable) Server connect and upload as many new ENS data records as are available (S2201). Then, the Client advertises and scans for connectable W-ENS beacons (S2202). Then, the client transmits an HCI_Create_Connection message to the server (S2203). And, the client receives the HCI_Command_Status message from the server (S2204). Then, the ENS data record is uploaded between the client and the server (S2205).

Table 26 shows an example of an advertisement format of a beacon advertised by the wearable when placed in pairing mode.

Referring to Table 26, wearables are provided with serial numbers and device secrets during manufacturing. The Gateway cloud backend can also access the serial numbers and corresponding device secrets of all devices used during the manufacturing process.

Next, the operation method of the wearable related to the Salpin ENS described above will be examined in more detail.

1. The wearable is turned on for the first time and enters pairing mode.

2. The wearable advertises in the format shown in FIG. 19 in the provisioning step.

3. Internet Gateway

- 3.1 Scan beacons.

- 3.2 The device determines if provisioning is required.

- 3.3 The gateway extracts the bytes at offsets 12-27 from the beacon.

- 3.4 Match the extracted 16 bytes with the LSB of the device ID hash entry as shown in Table 29.

- 3.5 If the gateway finds a matching entry, it extracts the entry from Table 29 and proceeds to the next step (step 4). Otherwise, the gateway ignores the beacon and stops the provisioning process.

4. The gateway starts provisioning to the device and creates a GATT connection with the wearable.

5. Gateway initiates ECDHE key exchange.

6. ECDHE key exchange takes place to derive the 128-bit secret(k).

7. To prevent other devices from replicating/spoofing this beacon and impersonating it as an authentic device, it is requested to present 16 MSB of the computed device ID hash.

- 7.1 Wearable encrypts 16 MSBs using the derived secret k.

- 7.2 The gateway receives the encrypted payload calculated in step 7.1 and decrypts it with key k.

- 7.3 If the gateway can match the extracted payload of the 16 MSBs transmitted by the wearable with the MSB of the entry/entries extracted in step 3.5, the gateway marks the wearable as authentic. Otherwise, the connection is broken, indicating that provisioning failed because the device is not an authenticating device. If authentication succeeds, go to step 8.

8. If the wearable is successfully authenticated, the Gateway configures the wearable with the appropriate ENS system. Then, the wearable starts advertising in the ENS beacon format at advertising intervals specified in the ENS Spec.

9. If the wearable has data to offload, the wearable advertises in a beacon format as shown in FIG. 19, but the payload is changed as follows.

- 9.1 Set the ENS flag set to 0x02.

- Change the 9.2 byte 12-27 payload as follows.

Cut it into 16 bytes.

The truncated hash is the advertised device ID and should be updated on the beacon every 15 minutes. Since the Internet gateway shared the secret k derived in step 8, it can verify the unique ID broadcast by the device.

Depending on whether the wearable uses a real clock or a counter-based clock, if Didh in Equation 1 can use a counter or time for calculations. Therefore, Beacon may be similar to that shown in Table 28 below.

The ENS service scans for beacons in the background, typically scanning for 4 seconds every 5 minutes according to the A/G spec. Advertising occurs on multiple channels. During a scan, the wearable can detect multiple identical BLE beacons. If the wearable keeps storing all the beacons, the memory will run out very quickly. Consider a scenario where a family buys two similar wearables, and if the two wearables are in close proximity overnight, the wearable's memory can become full very quickly once it starts storing all the beacons it scans. Thus, instead of storing all beacon payloads, the wearable can optimize storage by storing the ENS payload following the number of pairs (RSSI, timestamp) once for a period of time about 15 minutes. Table 29 shows an example of the ENS payload format.

Bits of the Flags field may be defined as shown in Table 30 below.

Next, an embodiment of implementing the salpin W-ENS described above will be described.

23 is a flowchart showing an example of a method for confirming whether or not COVID-19 is infected through the W-ENS proposed in this specification.

Referring to FIG. 23 , the wearable device transmits an advertisement message including exposure notification information indicating whether it has been exposed to COVID-19 (S2310).

The advertisement message is configured in the format of FIG. 12 as reviewed above, and the exposure notification information can be identified by a 16-bit service UUID included in the advertisement message. And, the advertising message may be called a W-ENS beacon.

The advertisement message may be broadcast in units of 200-270 milliseconds.

The wearable device may be a smart watch, a smart band, and the like.

Thereafter, when the mobile terminal receives an advertisement message including exposure notification information indicating that it has been exposed to COVID-19 at the time of entering the range or area where the advertisement message broadcast from the wearable device can be received, the mobile terminal outputs an alarm message to inform the user that exposure to COVID-19 has occurred in the corresponding range or region through the output unit through at least one of visual, auditory, or tactile methods (S2320).

The mobile terminal may be a smart phone, a mobile phone, a laptop computer, a PC, a tablet, and the like.

Thereafter, the mobile terminal receiving the advertisement message including the exposure notification information indicating exposure to COVID-19 transmits the exposure notification information to other mobile terminals (relay node, edge node) on the mesh network through a flooding method or a routing method. A message including is transmitted (S2330).

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), flash memory, etc.) In addition, the program command includes not only machine language codes generated by a compiler, but also high-level language codes 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 satisfied. 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 change 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. Therefore, 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.

100: wireless communication system 110: client device
120: server device

Claims (1)

In the method for preventing the spread of infection of COVID-19, the method performed by the mobile terminal,
Receiving an advertising message from the wearable device including exposure notification information indicating whether it has been exposed to COVID-19;
The exposure notification information is identified by a 16-bit service UUID;
To notify the user that exposure to COVID-19 has occurred in the area when an advertisement message including exposure notification information indicating exposure to COVID-19 has been received at the time of entering an area where the advertisement message can be received outputting an alarm message through an output unit of the mobile terminal through at least one of a visual, auditory, or tactile method; and
A method comprising transmitting a message including exposure notification information indicating exposure to COVID-19 to another mobile terminal on the mesh network through a flooding method or a routing method.

Images