Electronic Shelf Label Profile

The ESL Profile specifies how a central access point (AP) may use the ESL Service exposed by an ESL device, and how the central AP communicates with ESLs connectionlessly when one or more ESLs are in the Synchronized state.

Each capability of this specification shall be supported in the specified manner. This specification may provide options for design flexibility, because, for example, some products do not implement every portion of the specification. For each implementation option that is supported, it shall be supported as specified.

The ESL Profile requires the Object Transfer Profile (OTP) [6].

The ESL Profile is compatible with the Bluetooth Core Specification [3], Version 5.4 or later.

The ESL Profile specifies two roles. A device shall support one of the following roles:

Electronic Shelf Label (ESL) – A device that can display a graphic (e.g., containing a price) for an item that is offered for sale on a shelf and that typically includes integrated sensors and light-emitting diodes (LEDs).

Access Point (AP) – A central device that can exchange data with many ESLs in a system by using Bluetooth wireless technology.

The GATT role is determined as follows:

2.2.4. Role, service, and profile diagram

Figure 2.1 summarizes the relationships between profile roles and associated services. The ESL Profile roles (AP and ESL) are represented by light gray boxes. Services are represented by gray boxes. The black boxes represent OTP roles.

Figure 2.1. Relationship between ESL Profile roles and services

No concurrency limitations or restrictions are imposed by this specification.

An AP shall use the Generic Access Profile (GAP) Central role.

An ESL shall use the GAP Peripheral role.

An AP may bond with multiple ESLs, typically thousands.

An ESL shall be bonded with a maximum of one AP at any one time.

This specification uses only the Bluetooth Low Energy (LE) transport.

The Object Server shall support the Object Action Control Point Write procedure described in Section 3.3.2.6 of the OTS [7]. Objects representing image storage locations shall pre-exist on the Object Server without requiring an Object Client to create them. An empty image storage location shall be represented by an object with zero contents; the object and its associated metadata shall exist even when the object has zero contents.

The following object metadata shall be populated for each object: object name, object type, object size, and object properties. Support for the Object Metadata characteristics that expose these values is required by the OTS [7].

The object type may be either a 16-bit or 128-bit Universally Unique Identifier (UUID) that identifies the type of the Current Object. UUIDs that use the 16-bit format are specified in the Bluetooth SIG Assigned Numbers [2]. Manufacturers may also assign their own UUIDs using the 128-bit format, which may be used for proprietary image formats.

The number of objects exposed shall be equal to the maximum number of images that the ESL device can store. This number can be found from the value of the ESL Image Information characteristic (see Section 4.2.1.6).

None of the objects shall support the Delete property.

For each object exposed by the Object Server representing an image storage location, the Write property shall be set as follows:

The Object Server shall support the Truncate feature described in Section 3.3.2.6 in the OTS [7]. If the Write property of an object is set to True, then the Truncate property shall also be set to True.

If the ESL supports one or more vendor-specific opcodes as described in the ESL Service [5], then the ESL shall support the PnP ID characteristic (and may support additional characteristics) in the Device Information Service.

The AP shall support the PAwR feature specified in the Bluetooth Core Specification [3] as a Central device.

The length of the Periodic Advertising Interval, the length of the Periodic Advertising Subevent Interval, and the number of subevents are left to the implementation.

Timing information for PAwR is provided by the AP in the Periodic Advertising Sync Transfer procedure as described in [Vol 6], Part B, Section 5.1.13 of [3]. After the AP has been configured for a given installation, the timing information shall remain constant.

The number of available response slots can be determined by the AP using the parameter Num_Response_Slots of the HCI_LE_Set_Periodic_Advertising_Parameters [v2] command described in [Vol 4], Part E, Section 7.8.61 of [3]. An ESL Payload typically includes multiple commands as described in Section 5.3.1.3. The AP should select values for subeventInterval, responseSlotDelay, and responseSlotSpacing that result in sufficient response slots to service the maximum demand. The maximum possible demand for response slots occurs when each command present in the ESL Payload requires a response from a different ESL, and the number of commands contained in the ESL Payload is the highest possible.

The first Periodic Advertising Response Slot following the Periodic Advertising Response Slot Delay is the response slot number 1 described in Section 5.3.1.4.2.

Refer to Section 5.3 for additional requirements that apply to the PAwR feature.

The AP shall perform Primary Service Discovery using either the GATT Discover All Primary Services sub- procedure or the GATT Discover Primary Services by Service UUID sub-procedure.

The AP shall discover the ESL Service [5].

The AP shall discover the Device Information Service [4], if the Device Information Service is exposed by the ESL.

The AP may also discover other services.

Requirements in this section represent a minimum set of requirements for a Client. Other GATT sub- procedures may be used if supported by both Client and Server.

Table 4.2 summarizes additional GATT sub-procedure requirements beyond those required by all GATT Clients.

The AP shall support the Object Client role of the OTP [6].

The Object Client shall support the Write Object Contents procedure described in Section 4.5.5.2 in the OTP [6]. The Object Client should also support the Go To procedure of the Object List Control Point as described in the OTP.

When using an OTP procedure to write image data to an ESL, the AP should set the Truncate bit of the Mode parameter to True so that the object is automatically resized if a larger image in the selected image storage location is to be overwritten by a smaller image, as described in Section 3.3.2.6 in the OTS [7].

An AP shall scan for ESLs in the Unassociated state by using the General Discovery procedure as described in GAP (see [Vol 3], Part C, Section 9.2.6 of [3]). An AP may determine which ESLs are in the Unassociated state by comparing the Bluetooth address of an ESL with a list of Bluetooth addresses of ESLs that have already been associated.

When the AP finds an ESL in the Unassociated state that the AP will configure, the AP shall initiate a connection to the ESL. After connecting to the AP, the ESL transitions into the Configuring state as described in Section 5.2.

An ESL can enter the Configuring state only from the Unassociated state. To transition an ESL from the Unassociated state to the Configuring state, the AP shall form a secure connection with the ESL, using LE Secure Connections and LE security mode 1 and security level 2, or higher, and shall establish a bond, as described in GAP (see [Vol 3], Part C, Section 9.4.4 of [3]). The Configuring state allows an ESL to be configured by the AP by using the ESL Service [5] that is exposed by the ESL.

The AP shall read the ESL Display Information characteristic (Section 4.2.1.5), ESL Image Information characteristic (Section 4.2.1.6), ESL Sensor Information characteristic (Section 4.2.1.7), and ESL LED Information characteristic (Section 4.2.1.8), insofar as these characteristics are exposed by the ESL.

If the Device Information Service PnP ID characteristic is exposed by the ESL, then the AP shall read the value of the PnP ID characteristic. The value of the PnP ID characteristic identifies the vendor of the device. The AP may use the value of the PnP ID characteristic to determine what vendor-specific opcodes, if any, may be supported by the ESL.

The AP shall configure the ESL by writing an ESL Address it has assigned to the ESL to the ESL Address characteristic (Section 4.2.1.1), the AP Synchronization Key Material to the AP Sync Key Material characteristic (Section 4.2.1.2), and the ESL Response Key Material to the ESL Response Key Material characteristic (Section 4.2.1.3). The AP shall write a value to the ESL Current Absolute Time characteristic (Section 4.2.1.4) representing the current system time.

See an example MSC in Section 6.1.1.

The AP may also write images to the ESL in the Configuring state, using the Object IDs that it has derived as described in Section 4.2.1.6 and the procedures specified in the OTP [6].

After configuration of the ESL has been completed, the AP shall send the Update Complete opcode using the ESL Control Point characteristic and shall commence the Periodic Advertising Synchronization Transfer (PAST) procedure described in the Bluetooth Core Specification [3] to transition the ESL to the Synchronized state. This process is illustrated in Section 6.1.5. When the ESL receives the Update Complete command, the ESL shall wait for synchronization to be established and then terminate the ACL connection and transition to the Synchronized state.

However, if link loss occurs before configuration of the ESL has been completed, the AP should not commence the PAST procedure and should attempt to reconnect to the ESL to continue the configuration process. When link loss occurs before configuration of the ESL has been completed, the ESL reverts to the Unassociated state described in Section 5.1.

For ESLs in the Synchronized state, an AP shall transmit synchronization packets (see Section 5.3.1) for each group of ESLs in sequence by using the PAwR feature described in Section 4.1.

The AP shall support the authentication of ESL data using the Encrypted Advertising Data feature.

The format of the synchronization packet used in the Synchronized state is described in Section 5.3.1. If a command is sent and requires a response, then the AP shall process the response received.

Responses received in the Synchronized state shall be processed in the same way as is described for processing ESL responses from the ECP.

To provide enhanced reliability, the state information of the ESL response may be checked against the desired state of that ESL as known by the AP. If there is a difference between these two states, then the AP may schedule retransmission of an appropriate command to request that the ESL change its state to match the expected state.

See example MSCs in Section 6.2.

5.3.1. Synchronization packet

The synchronization packet for commands and responses is specified as a message contained within an Encrypted Data data type. The payload of the Encrypted Data data type shall be the ESL Payload contained in an ESL data type.

The ESL Payload shall be less than or equal to 48 octets in length.

The structure of the ESL Payload is described in Section 5.3.1.3 to Section 5.3.1.5.

5.3.1.1. ESL data type

The ESL data type contains an ESL command or response. The value shall be the same as the ESL Payload.

5.3.1.1.1. Format

Data Type	Description
«ESL»	The value shall be an ESL Payload

Table 5.1. ESL data type

5.3.1.2. ESL advertising packet

The synchronization packet is contained in an advertising packet as shown in Figure 5.1.

Figure 5.1. Synchronization packet in an advertising packet

5.3.1.3. Specific requirements for commands

The AP may send commands to ESLs that are in the Synchronized state.

Multiple ESLs may be addressed in a single synchronization packet, and the same ESL may be addressed more than once in the same synchronization packet.

The synchronization packet format used to send commands to ESLs is shown in Figure 5.2.

Figure 5.2. Synchronization packet for commands

The ESL Payload shall contain a Group_ID followed by one RFU field and then one or more commands. The Group_ID is a 7-bit value and is a part of the ESL Address format as described in the ESL Service [5]. A synchronization packet in which the Group_ID field has the value N shall be transmitted in a Periodic Advertising with Responses subevent with the subevent number N; therefore, the Group_ID maps to a specific Periodic Advertising with Responses subevent.

The RFU field consists of a single bit that shall be set to 0. Therefore, the Group_ID field and the RFU field together occupy 1 octet.

Each command consists of one TLV formatted element. Each TLV may have a different length. Although Figure 5.2 shows only three TLVs for illustration purposes, any number of TLVs may be included provided that the maximum ESL Payload size of 48 octets is not exceeded.

The format of a TLV is shown in Figure 5.3.

Figure 5.3. Command TLV format

The commands themselves each contain an ESL_ID, in a parameter, providing the remainder of the address of an ESL belonging to the group specified by the Group_ID. The ESL_ID value, 0xFF, known as the Broadcast Address, shall be reserved for broadcast messages as described in Section 5.3.1.5.

5.3.1.3.1. Opcodes for commands

The TLV format, opcodes, and parameters that are used to represent commands in the Synchronized state are identical to those used with the ECP described in the ESL Service [5]. However, in the Synchronized state, multiple commands can be sent at once in the same synchronization packet.

The total length of the Parameters field that follows each opcode in a synchronization packet can be calculated from the value of the Length field; the total length of the Parameters field shall be equal to (Length + 1) octets.

In each command, the first parameter, consisting of the octet immediately following the opcode, is the ESL_ID parameter. The ESL_ID parameter value shall be set to the value of the least significant 8 bits of the ESL Address as described in the ESL Service [5], or to the Broadcast Address as described in Section 5.3.1.5. Therefore, a single synchronization packet may contain a mixture of commands addressed to different ESLs.

The Factory Reset command described in the ESL Service [5] is reserved for use in the Configuring state and the Updating state (i.e., the AP shall not send the Factory Reset command to an ESL that is in the Synchronized state).

5.3.1.4. Specific requirements for ESL responses

When an ESL receives a synchronization packet containing one or more commands individually addressed to that ESL, the ESL shall transmit the response as described in this section.

The number of response slots and the response slot timings are determined by the AP using the PAwR feature, as described in Section 4.1.

The synchronization packet used to send an ESL response shall have the format shown in Figure 5.4.

Figure 5.4. Synchronization packet for ESL responses

The ESL Payload shall contain one or more ESL response TLVs. The format of each TLV used for an ESL response is shown in Figure 5.5.

Figure 5.5. ESL response TLV format

Each TLV may have a different length.

Each TLV represents the response to one of the commands received by the ESL.

When an ESL receives a synchronization packet containing one or more commands to which the ESL will respond, the ESL shall send a single synchronization packet for ESL response. The single synchronization packet for ESL response sent by the ESL should contain responses to the commands that were individually addressed to the ESL, consisting of ESL response TLVs arranged in the same order as the command TLVs to which the ESL is responding (i.e., the ESL response TLV that is transmitted first should be the response to the command TLV that was received first). The process by which a response slot is allocated to the ESL for this purpose is described in Section 5.3.1.4.2. If including all the requested response TLVs would cause the maximum ESL Payload size of 48 octets to be exceeded, then the ESL shall substitute the Capacity Limit Error response described in the ESL Service [5] for one or more such response TLVs, such that the maximum ESL Payload size is not exceeded in the response.

5.3.1.4.1. Opcodes for responses

The opcodes and parameters used in the TLVs for ESL response data types sent by ESLs that are in the Synchronized state shall be the same as those used in notifications of the ESL Control Point characteristic as described in the ESL Service [5] (i.e., the TLVs that are used to represent ESL response data types in the Synchronized state are identical to the TLVs used to represent ESL responses that may be sent in the ESL Service by using GATT).

5.3.1.4.2. Allocation of response slots to ESLs

A synchronization packet received from an AP may contain commands addressed to multiple ESLs, but an ESL shall send a response only to commands individually addressed to itself.

For the purposes of the allocation of response slots to ESLs, the command TLVs received in a synchronization packet shall be numbered as follows: the TLV received first in the ESL Payload from the AP shall be TLV number 1, the TLV received second in the same ESL Payload shall be TLV number 2, and the Nth TLV received in the same ESL Payload shall be TLV number N. These are referred to as TLV_1, TLV_2, etc., as illustrated in Figure 5.6.

Figure 5.6. Numbering of command TLVs received from an AP

The response slot in which a particular ESL shall transmit its response shall be determined as follows:

1. For the purposes of the following procedure, broadcast messages (see Section 5.3.1.5) shall be disregarded because broadcast messages do not elicit a response. The expression ”individually addressed” in the following steps describes a command that is not a broadcast message.

2. If the ESL receives only one command individually addressed to itself in the synchronization packet received, then the command shall be the relevant command for step 4 below.

3. If the ESL receives more than one command individually addressed to itself in the same synchronization packet, then the command that the ESL receives last shall be the relevant command for step 4 below.

4. If an ESL receives a relevant command in TLV number N, then the ESL shall transmit its response (if any) in response slot N.

5. An ESL shall not transmit in any timeslot other than the response slot that was assigned to that ESL through the process described in step 4.

6. However, an ESL may indicate that it has not had sufficient time to give a response (e.g., because the required sensor hardware was asleep) by requesting that the AP ask again in the next frame time. The ESL shall do this by sending the ESL response error code for Retry, described in the ESL Service [5], in the ESL’s allocated response slot.

For example, if an AP sends a synchronization packet containing seven commands (TLV_1 to TLV_7), in which:

• TLV_1 and TLV_3 are both individually addressed to the same ESL (”ESL A”);

• TLV_2 is individually addressed to ESL B;

• TLV_4 is a broadcast message;

• TLV_5 and TLV_6 are individually addressed to ESL C; and

• TLV_7 contains a broadcast message,

then the allocation of the response slots to the ESLs must be as shown in Table 5.2.

Response slot number	ESL that transmits its response	Command(s) responded to
1	See Note	None
2	ESL B	TLV_2
3	ESL A	TLV_1, TLV_3
4	See Note	None
5	See Note	None
6	ESL C	TLV_5, TLV_6
7	See Note	None
Other slots	Not used	None

Table 5.2. Example of allocation of response slots

Note: In the example shown in Table 5.2, response slots 1 and 5 are not used because the ”relevant” commands for the ESLs concerned are allocated to later response slots as described in steps 3 and 4 above. Response slots 4 and 7 are not used because a broadcast message does not elicit any response.

5.3.1.4.3. Error handling

When an error condition occurs that prevents a command from being executed successfully, the ESL response data type ”Error” shall be sent as the response to that command, with the parameter value set to the relevant error code, as described in the ESL Service [5].

When an ESL receives a synchronization packet containing multiple commands addressed to the ESL, and if an error condition occurs when processing one of those commands, the ESL shall continue processing the other commands received in the same synchronization packet.

5.3.1.5. Specific requirements for broadcast messages

In addition to the transmission of individually addressed messages, an AP shall also support the sending of a broadcast message to an entire group of ESLs, by using the Broadcast Address in conjunction with the Group_ID as described in Section 5.3.1.3. In this case, the Group_ID field shall be set to the Group_ID for the group and the ESL_ID field (e.g., within a command) shall be set to the Broadcast Address value, 0xFF.

All ESLs associated with the relevant Group_ID that receive the broadcast message shall process it (e.g., all the ESLs relating to a given product type, such as fresh vegetables, may be sent the same command in a single transmission).

However, as described in Section 3.1.3, broadcast messages do not elicit any response from an ESL.

To enhance reliability, the AP may subsequently poll the ESLs to verify that the command has been received and executed.

The AP may request an ESL to transition to the Updating state as described in Section 5.3 or Section 5.5.

As a prerequisite of entering the Updating state, the ESL shall already be bonded with the AP, having formed the bond during a previous connection between the same peer devices (see Section 5.2).

The previously bonded AP is a trusted device, and any other device is an untrusted device. If the ESL connects to the trusted device, then the ESL shall enter the Updating state. The ESL may reject a connection request from an untrusted device. However, if the ESL does connect to a device other than the trusted device, the ESL shall reject any pairing request received from that device, and the ESL shall not enter the Updating state while connected to the untrusted device.

When in the Updating state, an ESL can be reconfigured by writing to the applicable characteristics that were described in Section 5.2, and the AP may write commands to the ECP. See the example MSCs in Section 6.1.

The AP may also write images to the ESL in the Updating state, using Object IDs that it has derived as described in Section 4.2.1.6 with the procedures specified in the OTP [6]. This may include overwriting images that have previously been stored in the ESL.

If the AP requires updating the AP Sync Key Material value, then the AP should coordinate the change in AP Sync Key Material methodically across all the ESLs that need to be updated.

After the updates have been completed, the AP shall send the Update Complete opcode using the ESL Control Point characteristic and shall start the PAST procedure described in the Bluetooth Core Specification [3] to transition the ESL to the Synchronized state. This process is illustrated in Section 6.1.5. If an ESL receives the Update Complete command and it is synchronized, the ESL shall immediately terminate the ACL connection and transition to the Synchronized state.

If an ESL receives the Update Complete command and it is not synchronized, the ESL shall wait for synchronization to be established and then terminate the ACL connection and transition to the Synchronized state.

However, if link loss occurs before all the required updates of the ESL have been completed, the AP should not start the PAST procedure and should attempt to reconnect to the ESL to complete the updates. When link loss occurs in the Updating state, the ESL transitions to the Unsynchronized state described in Section 5.5.

The AP shall scan for ESLs in the Unsynchronized state by using the General Discovery procedure as described in GAP (see [Vol 3], Part C, Section 9.2.6 of [3]). When in the Unsynchronized state, an ESL is associated with an AP but is not in a connection and is not synchronized. In the Unsynchronized state, the ESL is in a GAP connectable mode until it is connected with the associated AP, at which point the ESL will transition from the Unsynchronized state to the Updating state. An AP may determine which ESLs are in the Unsynchronized state by comparing the Bluetooth address of an ESL with a list of Bluetooth addresses of ESLs that have been associated.

When the AP finds an ESL in the Unsynchronized state, and the ESL is associated with the AP, the AP shall initiate a connection to the ESL by using a Connection Establishment procedure described in GAP (see [Vol 3], Part C, Section 7.3 of [3]). Once connected, the ESL transitions to the Updating state, as shown in the ESL state diagram in Section 2.7.3 of the ESL Service [5].

This section provides example message sequences used in the connection-oriented Configuring and Updating states. GATT services are used in these states.

6.1.1. Configure or Reconfigure an ESL procedure

In this procedure, an AP configures an ESL through a secure connection created using the Securing ESLs procedure. Configuration is accomplished by reading and writing characteristics in the ESL Service.

Figure 6.1. MSC example: Configure or reconfigure an ESL

The sequence in Figure 6.1 is presented for illustration only. Messages may occur in a different order and an ESL implementation may support fewer readable characteristics than shown in Figure 6.1.

The transactions used for initial configuration, in the Configuring state, and for reconfiguration, in the Updating state, are effectively the same except that, in the Updating state, it is only necessary to access the characteristics impacted by changes.

6.1.2. Update a Stored Image on an ESL procedure

In this procedure, information is obtained from the ESL Image Information characteristic that enables image data to be written to a given stored image by using the OTP [6] and OTS [7].

Figure 6.2. MSC example: Update a stored image on an ESL

6.1.3. Control LED(s) in Updating State procedure

In this procedure, an AP changes the state of the LED(s) exposed by an ESL in the Updating state by writing to the ECP.

Figure 6.3. MSC example: Change the state of LED(s) on an ESL

6.1.4. Transition to Unassociated State procedure

In this procedure, the AP instructs an ESL to transition from the Updating state to the Unassociated state by using the Unassociate from AP command, which is written to the ECP characteristic.

Figure 6.4. MSC example: Transition to the Unassociated state

6.1.5. Transition to Synchronized State When Synchronized procedure

In this procedure, the ESL transitions to the Synchronized state when the ESL is synchronized. Once synchronized, the ESL terminates the connection-oriented link.

Figure 6.5. MSC example: Transition to the Synchronized state when synchronized

6.1.6. Transition to Synchronized State When Not Synchronized procedure

In this procedure, the ESL transitions to the Synchronized state when the ESL is not synchronized. Once synchronized, the ESL terminates the connection-oriented link.

Figure 6.6. MSC example: Transition to the Synchronized state when not synchronized

This section describes messages that may be sent and received in the Synchronized state, using the PAwR feature as described in Section 5.3.

6.2.1. Control LED in Synchronized State procedure

In this procedure, the AP sends a command to an ESL in the Synchronized state to control an LED.

Figure 6.7. MSC example: Control an LED in the Synchronized state

The timed or non-timed version of the LED Timed Control and LED Control commands may be used. Only the LED Control command has been shown in Figure 6.7, for simplicity.

6.2.2. Control Displayed Image in Synchronized State procedure

In this procedure, the AP sends a command to an ESL in the Synchronized state to control the displayed image on a display.

Figure 6.8. MSC Example: Control the displayed image in the Synchronized state

The timed or non-timed version of the Display Timed Image and Display Image commands may be used. Only the Display Image command has been shown in Figure 6.8, for simplicity.

6.2.3. Read Sensor Data in Synchronized State procedure

In this procedure, the AP sends a command to an ESL in the Synchronized state to initiate the reading of a sensor on the ESL.

Figure 6.9. MSC example: Read sensor data in the Synchronized state

6.2.4. Check ESL is Still in Synchronized State procedure

In this procedure, an AP checks that an ESL is still synchronized with the AP. The frequency with which these messages are sent is left to the implementer.

Figure 6.10. MSC Example: Check the ESL is still in the Synchronized state

6.2.5. Move from Synchronized to Updating State procedure

In this procedure, the AP instructs an ESL to transition from the Synchronized state to the Updating state by initiating a connection with the ESL.

Figure 6.11. MSC Example: Transition to the Updating state

Any connection between an AP and an ESL shall use LE Secure Connections and LE security mode 1 and security level 2, or higher, as described in GAP (see [Vol 3], Part C, Section 10.2 of [3]). Bonding is required as described in Section 5.2 and Section 5.4. The stored Long-Term Key is used when transitioning to the Updating state from the Synchronized or Unsynchronized state.

In the Synchronized state, the AP shall use the Encrypted Advertising Data feature as described in Section 5.3.

The AP Sync Key Material is described in Section 4.2.1.2. The AP shall use the same AP Sync Key Material value with all ESLs in a system.

The ESL Response Key Material is described in Section 4.2.1.3. The AP shall configure each ESL with an ESL Response Key Material value. The AP should assign a different ESL Response Key Material value for each ESL in the system. This enables ESL responses sent in the Synchronized state to be authenticated by the AP.

The AP shall include a new Randomizer value in each synchronization packet that the AP transmits.

In the Synchronized state, the ESL shall use the Encrypted Advertising Data feature as described in Section 3.1.3.

An ESL message is valid if the Encrypted Advertising Data Message Integrity Check (MIC) does authenticate.

As described in the ESL Service [5], if an ESL does not receive a valid ESL message in a synchronization message for 60 minutes, then the ESL transitions to the Unsynchronized state. Once in the Unsynchronized state, the ESL can return to the Synchronized state only through the Updating state.

Therefore, an ESL can be temporarily absent for periods less than 60 minutes in duration without leaving the Synchronized state; this time might be used, for example, to update an e-ink display (e.g., when there is an insufficient energy budget available to support Bluetooth wireless communications while the limited battery power is being used to accomplish the display update).

The ESL shall include a new Randomizer value in each response packet that the ESL transmits.