Bluetooth 4.0 Technical Analysis 1-broadcaster role

Source: Internet
Author: User

Chapter 2 Bluetooth Roles-Broadcaster1.1 broadcast type

You can set the following types for broadcast:

1) connectable undirected Event Type)

2) connectable directed event type (connectable)

3) scannable undirected event type (no targeted broadcast can be scanned)

4) Non-connectable undirected event type (non-connectionless broadcast)

The so-called targeting and untargeting are for broadcast objects. If it is for a specific object broadcast (the PDU in the broadcast package will contain the bd_addr of the target object), it is for targeted broadcast, otherwise, it is not targeted. Connectionless and connectionless means whether to accept connection requests. If it is a broadcast type that is not connectionless, it will not respond to connection requests. The scan type refers to responding to the scan request.

 

Implemented in ticc2540:

The broadcast type is located in (include/gap. h). The specific types are defined as follows:

Gap_adtype_adv_ind //! <Connectable undirected Advertisement

Gap_adtype_adv_hdc_direct_ind //! <Connectable high duty cycledirected Advertisement

Gap_adtype_adv_scan_ind //! <Scannable undirected Advertisement

Gap_adtype_adv_nonconn_ind //! <Non-connectable undirected Advertisement

Gap_adtype_adv_ldc_direct_ind //! <Connectable low duty cycle directed Advertisement

There are two methods (high duty cycle and low duty cycle) for the connectable broadcast type)

The API set for parameters is:

Gaprole_setparameter (gaprole_adv_event_type, sizeof (uint8), & advtype );

1.1.1 connectable undirected Event Type

The connectable non-oriented broadcast package is (adv_ind PDU ). In a connectable non-targeted broadcast type, a scanner or initiator can respond to the broadcast package using scan requests or connection requests. The scanner can send a scan request (scan_req PDU) to obtain additional broadcast information (scan_rsp); the initiator can send a connection request (connect_req PDU) to require the link layer to enter the link status.

The link layer must listen to requests from the scanner or initiator on the same broadcast channel.

If the broadcaster receives a scan request packet (scan_req PDU), The request contains its device address and the scanner is allowed by the broadcast filter policy, then the broadcaster will respond to a packet (scan_rsp PDU) on the same channel ). When (scan_rsp PDU) is sent, or because the broadcast filter policy blocks this request packet, the broadcaster moves to the next broadcast channel to send another broadcast packet (adv_ind PUD ), or disable broadcast events.

If a broadcaster receives a connection request packet (connect_req PDU), The request contains its device address and the initiator is allowed by the Broadcast Policy, the link layer will exit the broadcast status and be transferred to the connection status, and the role will be converted to "Slave Device ". If the broadcast filter policy blocks this connection request packet, the broadcaster moves to the next broadcast channel to send another broadcast packet (adv_ind PUD) or disable broadcast events.

The interval between two adjacent broadcast packets (adv_ind PDU) in a broadcast event is less than or equal to 10 ms, and the broadcast status is disabled within the advertising interval.

A broadcast event that does not scan requests and connection requests (using all broadcast channels 37, 38, and 39) is shown in:

()


A broadcast event that contains scan requests (using all broadcast channels 37, 38, and 39) scans requests in the middle of a broadcast event, as shown in:

()


A broadcast event containing scan requests (using all broadcast channels 37, 38, and 39) that scans requests at the end of a broadcast event, as shown in:

()


A broadcast event that contains connection requests, as shown in :()


1.1.2 connectable directed Event Type

The connectable targeted broadcast package is (adv_direct_ind PDU ). This type allows an initiator to respond to (connect_req PDU) the broadcast package in a connection request package. The initiator sends a connection request package and requests the linklayer to enter the connection status.

The connectable adv_direct_ind PDU contains both the initiator device address and the broadcaster device address. Only the initiator meeting the address can initiate a connection request (connect_req PDU) to the broadcaster. That is to say, when the initiator receives the broadcast package, it will check whether it is consistent with its own address. If it is inconsistent, it will discard the package without any response. If it is its own address, it will submit it to the host layer, the host layer determines whether to initiate a connection request.

When the broadcaster sends a broadcast package (adv_direct_ind PDU), It listens to the connection request package (connect_reqpdu) on the same channel ). Any scan package is ignored, that is, scan requests are not accepted.

If a broadcaster receives a connection request packet containing its device address and the initiator is the specified destination of the broadcast package, the Link Layer) the role will exit the broadcast status and be transferred to the connection status, and the role will be changed from the broadcaster to the slave device ". Otherwise, the broadcaster switches to the next broadcast channel to send the next broadcast packet, or closes the broadcast event.

The interval between two adjacent broadcast packets on the same broadcast channel is less than or equal to 3.75 Ms. It can be seen that the broadcast speed of this type is much faster than that of a non-oriented broadcast packet (<= 30 ms.

After entering the broadcast status, the link layer will exit the broadcast status within 1.28s.

A sequence diagram of two broadcast events with no connection request (connect_req PDU) and five broadcast packets (adv_direct_ind PDU) is shown as follows:

()


Application Scenario: A connectable type of targeted broadcast is used to quickly establish a connection (for example, reconnect ).

1.1.3 scannable undirected Event Type

The untargeted broadcast package (adv_scan_ind PDU) can be scanned, allowing a "scanner" to respond to a scanning request packet (san_req PDU) to obtain additional information (scan_rsp) from the "broadcaster ).

The link layer monitors requests from the scanner on the same channel.

If the broadcaster receives a scan request packet containing its address (scan_req PDU) and the address of the scanner complies with the filter Policy (that is, the device is legal, if it is not filtered by the address filtering policy of the broadcaster, the broadcaster will respond to a packet (scan_rsp PDU) on the same broadcast channel ). When the scan_rsp PDU packet is sent completely or scan_req is blocked by the filter policy, the broadcaster switches to the next broadcast channel to send the next broadcast packet or close the broadcast event.

The interval between two adjacent broadcast packets (adv_ind PDU) in a broadcast event is less than or equal to 10 ms, and the broadcast status is disabled within the advertising interval.

The packet sequence without scanning requests is shown as follows :()


The packet sequence with scan requests is shown below. One scan request is in the middle, and the other scan request is at the end :()


()

1.1.4 non-connectable undirected Event Type

A non-targeted broadcast packet (adv_nonconnn_ind PDU) cannot be connected. This broadcast type does not accept any request packets (including scan requests and connection requests ), the scanner can receive broadcast packets from the broadcaster.

The interval between two adjacent broadcast packets (adv_ind PDU) in a broadcast event is less than or equal to 10 ms, and the broadcast status is disabled within the advertising interval.

Broadcast events are shown in :()

1.2 broadcast-related parameters

Broadcast-related configurable parameters include:

1) advertising_interval_min

2) advertising_interval_max,

3) advertising_type,

4) own_address_type,

5) direct_address_type,

6) direct_address,

7) advertising_channel_map,

8) advertising_filter_policy

9) advertisingdata

10) scanreponse data

1.2.1 advertising Interval

First, we will introduce advertising interval (broadcast interval): the interval between two adjacent broadcast events (t_advevent) is:

T_advevent = advinterval + advdelay

The advinterval value must be an integer multiple of 0.625ms and the value range is between 20ms-10.24s. For the two types of "scanable non-targeted broadcast" and "inaccessible non-targeted broadcast, the value should be no less than 100 ms (that is, at least 160 0.625 ms). For connectable non-oriented broadcast, the value can be set to 20 ms-10.24 S.

Advdelay is a pseudo-random number allocated by the link layer. Its range is 0-10 ms.

The interval between broadcast packets is as follows :()

The advertising_interval_min and advertising_interval_max parameters are used to adjust advertisinginterval. They are usually in the unit of 0.625ms. Here we set an upper and lower limits, the purpose is to allow the Controller to dynamically adjust the appropriate broadcast packet sending frequency based on its actual working conditions. Of course, you can also set it to the same value.

Advertising_interval_min size: 2 bytes

Value

Parameter description

N = 0 XXXXX

The minimum broadcast interval of a non-oriented broadcast packet.

Value Range: 0x0020-0x4000

Default Value: n = 0x0800 (1.28 seconds)

Time = N * 0.625 ms

Time Range: 20 ms-10.24 s

 

Advertising_interval_max size: 2 bytes

Value

Parameter description

N = 0 XXXXX

The maximum broadcast interval of a non-oriented broadcast packet.

Value Range: 0x0020-0x4000

Default Value: n = 0x0800 (1.28 seconds)

Time = N * 0.625 ms

Time Range: 20 ms-10.24 s

1.2.2 advertising_type

It is the various broadcast types introduced in this chapter.

Advertising_type size: 1 bytes

Value

Parameter description

0x00

Connectable undirected advertising (adv_ind) (default)

0x01

Connectable directed advertising (adv_direct_ind)

0x02

Scannable undirected advertising (adv_scan_ind)

0x03

Non connectable undirected advertising (adv_nonconn_ind)

0x04-0xff

Reserved for future use

 

The broadcast type determines the response packet type. The following table lists the comparison between SCAN requests and connection requests of various types:

Broadcast type

Broadcast package (PDU)

Response packet (PDU)

 

 

Scan request (scna_req)

Connection Request (connect_req)

Connectable non-targeted Broadcast

Adv_ind

Yes

Yes

Connectable targeted Broadcast

Adv_direct_ind

No

Yes

Unconnectable Broadcast

Adv_noconn_ind

No

No

Supports non-targeted broadcast scanning.

Adv_scan_ind

Yes

No

1.2.3 own_address_type

Own_address_type size: 1 bytes

Value

Parameter description

0x00

Public device address (default)

0x01

Random Device address

0x02-0xff

Reserved for future use

The device address type used by the broadcaster.

Device address type:

Public device address: the address of a public device is unique to a device and cannot be changed. Similar to the MAC address of a network device, the address length is 48 bits. This address is obtained from the IEEE registration authority and consists of two parts:

Company_id part: the high address part consists of 24 digits.

Company_assigned part: the low address part consists of 24 digits.

LSB MSB

Company_assigned (24-bit)

Company_id (24 bits)

 

Ramdom device address: Random Device address (Private device address), which is also 48 bits

LSB MSB

Hash (24-bit)

Random (24-bit)

1.2.4 direct_address_type,

The address type of the target.

1.2.5 direct_address,

The device address of the targeted object (which can be a public device address or a private device address based on the type)

1.2.6 advertising_channel_map

Selection of broadcast channels

Advertising_channel_map size: 1 bytes

Value

Parameter description

00000000b

Retained

Xxxxxxx1b

Allow 37 Channels

Xxxxxx1xb

Allow 38 Channels

Xxxxx1xxb

Allow 39 Channels

00000111b

Default (allow all broadcast channels)

1.2.7 advertising_filter_policy

The "broadcaster" filtering policy sets the filtering policy used by devices that send request packets:

Advertising_filter_policy size: 1 bytes

Value

Parameter description

0x00

Allow any scan requests and any connection requests (default)

0x01

Only scan requests from the whitelist are allowed, and any connection requests are allowed.

0x02

Any scan request is allowed. Only connection requests from the whitelist are allowed.

0x03

Only scan and connection requests from the whitelist are allowed.

0x04-0xff

Retained

1.2.8 advertising data

The broadcast data carried in a broadcast package cannot exceed 31 bytes (0-31). The data must comply with the following format requirements: (Multiple AD data segments can exist, each ad data segment consists of Length: data. The length is 1 byte, the Data Length is lenth, and the length of all ad segments is Length + 1 ). Broadcast data can be changed as needed. ()

1.2.9 reponse data

Scan the additional data in the request response. The maximum length is 31 bytes (0-31). The data packet format is the same as advertising data.

1.3 broadcast process (undirected advertising) 1.3.1 undirected advertising)

A Bluetooth device enters the broadcast status. The general process is as follows :()

1.3.2 targeted Broadcast

()

Implementation in 1.4 Ti 4X

Parameter settings:

Gaprole_setparameter (gaprole_scan_rsp_data, sizeof (scanrspdata), scanrspdata );

Gaprole_setparameter (gaprole_advert_data, sizeof (advertdata), advertdata );

Gaprole_setparameter (gaprole_adv_event_type, sizeof (uint8), & advtype );

Gap_setparamvalue (tgap_lim_disc_adv_int_min, advint );

Gap_setparamvalue (tgap_lim_disc_adv_int_max, advint );

Gap_setparamvalue (tgap_gen_disc_adv_int_min, advint );

Gap_setparamvalue (tgap_gen_disc_adv_int_max, advint );

Broadcast enabling (disabling ):

Gaprole_setparameter (gaprole_advert_enabled, sizeof (uint8), & initial_advertising_enable );


Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.