Mesh Binary Large Object Transfer Model

Abstract

The Mesh Binary Large Object Transfer Model specification describes the requirements to enable the transfer of binary large objects (BLOBs) between Bluetooth mesh devices.

Version: v1.0
Version Date: 2023-09-12
Prepared By: Mesh Working Group

Version History

Version Number	Date	Comments
v1.0	2023-09-12	Adopted by the Bluetooth SIG Board of Directors.

Acknowledgments

Name	Company
Simon Slupik	Silvair, Inc.
Piotr Winiarczyk	Silvair, Inc.
Krzysztof Tkaczenko	Silvair, Inc.
Jori Rintahaka	Silicon Laboratories
Omkar Kulkarni	Nordic Semiconductor ASA
Trond Einar Snekvik	Nordic Semiconductor ASA
Max Palumbo	Silicon Laboratories
Michał Budzoń	Silvair, Inc.
Max Palumbo	Katerra Inc.
Victor Zhodzishsky	Cypress Semiconductor Corporation

Use of this specification is your acknowledgement that you agree to and will comply with the following notices and disclaimers. You are advised to seek appropriate legal, engineering, and other professional advice regarding the use, interpretation, and effect of this specification.

Use of Bluetooth specifications by members of Bluetooth SIG is governed by the membership and other related agreements between Bluetooth SIG and its members, including those agreements posted on Bluetooth SIG’s website located at www.bluetooth.com. Any use of this specification by a member that is not in compliance with the applicable membership and other related agreements is prohibited and, among other things, may result in (i) termination of the applicable agreements and (ii) liability for infringement of the intellectual property rights of Bluetooth SIG and its members. This specification may provide options, because, for example, some products do not implement every portion of the specification. All content within the specification, including notes, appendices, figures, tables, message sequence charts, examples, sample data, and each option identified is intended to be within the bounds of the Scope as defined in the Bluetooth Patent/Copyright License Agreement (“PCLA”). Also, the identification of options for implementing a portion of the specification is intended to provide design flexibility without establishing, for purposes of the PCLA, that any of these options is a “technically reasonable non-infringing alternative.”

Use of this specification by anyone who is not a member of Bluetooth SIG is prohibited and is an infringement of the intellectual property rights of Bluetooth SIG and its members. The furnishing of this specification does not grant any license to any intellectual property of Bluetooth SIG or its members. THIS SPECIFICATION IS PROVIDED “AS IS” AND BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES MAKE NO REPRESENTATIONS OR WARRANTIES AND DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR THAT THE CONTENT OF THIS SPECIFICATION IS FREE OF ERRORS. For the avoidance of doubt, Bluetooth SIG has not made any search or investigation as to third parties that may claim rights in or to any specifications or any intellectual property that may be required to implement any specifications and it disclaims any obligation or duty to do so.

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES DISCLAIM ALL LIABILITY ARISING OUT OF OR RELATING TO USE OF THIS SPECIFICATION AND ANY INFORMATION CONTAINED IN THIS SPECIFICATION, INCLUDING LOST REVENUE, PROFITS, DATA OR PROGRAMS, OR BUSINESS INTERRUPTION, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, AND EVEN IF BLUETOOTH SIG, ITS MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF THE DAMAGES.

Products equipped with Bluetooth wireless technology ("Bluetooth Products") and their combination, operation, use, implementation, and distribution may be subject to regulatory controls under the laws and regulations of numerous countries that regulate products that use wireless non-licensed spectrum. Examples include airline regulations, telecommunications regulations, technology transfer controls, and health and safety regulations. You are solely responsible for complying with all applicable laws and regulations and for obtaining any and all required authorizations, permits, or licenses in connection with your use of this specification and development, manufacture, and distribution of Bluetooth Products. Nothing in this specification provides any information or assistance in connection with complying with applicable laws or regulations or obtaining required authorizations, permits, or licenses.

Bluetooth SIG is not required to adopt any specification or portion thereof. If this specification is not the final version adopted by Bluetooth SIG’s Board of Directors, it may not be adopted. Any specification adopted by Bluetooth SIG’s Board of Directors may be withdrawn, replaced, or modified at any time. Bluetooth SIG reserves the right to change or alter final specifications in accordance with its membership and operating agreements.

Copyright © 2020–2023. All copyrights in the Bluetooth Specifications themselves are owned by Apple Inc., Ericsson AB, Intel Corporation, Lenovo (Singapore) Pte. Ltd., Microsoft Corporation, Nokia Corporation, and Toshiba Corporation. The Bluetooth word mark and logos are owned by Bluetooth SIG, Inc. Other third-party brands and names are the property of their respective owners.

1. Introduction

This Mesh Binary Large Object Transfer Model specification defines models (along with their required states and messages) that are used to enable the transfer of binary large objects between nodes on a mesh network.

Terms, acronyms, and abbreviations that have a specific meaning in the context of this specification or the Bluetooth environment in general are defined or expanded upon on their first use. Defined terms that are used in this specification are listed in Section 1.7.

1.1. Language

1.1.1. Language conventions

In the development of a specification, the Bluetooth SIG has established the following conventions for use of the terms “shall”, “shall not”, “should”, “should not”, “may”, “must”, and “can”. In this Bluetooth specification, the terms in Table 1.1 have the specific meanings given in that table, irrespective of other meanings that exist.

Term	Definition
shall	—used to express what is required by the specification and is to be implemented exactly as written without deviation
shall not	—used to express what is forbidden by the specification
should	—used to express what is recommended by the specification without forbidding anything
should not	—used to indicate that something is discouraged but not forbidden by the specification
may	—used to indicate something that is permissible within the limits of the specification
must	—used to indicate either: an indisputable statement of fact that is always true regardless of the circumstances an implication or natural consequence if a separately-stated requirement is followed
can	—used to express a statement of possibility or capability

Table 1.1. Language conventions terms and definitions

1.1.1.1. Implementation alternatives

When specification content indicates that there are multiple alternatives to satisfy specification requirements, if one alternative is explained or illustrated in an example it is not intended to limit other alternatives that the specification requirements permit.

1.1.1.2. Discrepancies

It is the goal of Bluetooth SIG that specifications are clear, unambiguous, and do not contain discrepancies. However, members can report any perceived discrepancy by filing an erratum and can request a test case waiver as appropriate.

1.1.2. Reserved for Future Use

Where a field in a packet, Protocol Data Unit (PDU), or other data structure is described as "Reserved for Future Use" (irrespective of whether in uppercase or lowercase), the device creating the structure shall set its value to zero unless otherwise specified. Any device receiving or interpreting the structure shall ignore that field; in particular, it shall not reject the structure because of the value of the field.

Where a field, parameter, or other variable object can take a range of values, and some values are described as "Reserved for Future Use," a device sending the object shall not set the object to those values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous; however, this does not apply in a context where the object is described as being ignored or it is specified to ignore unrecognized values.

When a field value is a bit field, unassigned bits can be marked as Reserved for Future Use and shall be set to 0. Implementations that receive a message that contains a Reserved for Future Use bit that is set to 1 shall process the message as if that bit was set to 0, except where specified otherwise.

The acronym RFU is equivalent to Reserved for Future Use.

1.1.3. Prohibited

When a field value is an enumeration, unassigned values can be marked as “Prohibited.” These values shall never be used by an implementation, and any message received that includes a Prohibited value shall be ignored and shall not be processed and shall not be responded to.

Where a field, parameter, or other variable object can take a range of values, and some values are described as “Prohibited,” devices shall not set the object to any of those Prohibited values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous.

“Prohibited” is never abbreviated.

1.2. Table conventions

This section describes conventions regarding the following:

Requirements that are in a table
Indicating a cell that has no value or content

1.2.1. Requirements that are in a table

Unless otherwise stated, requirements that are in a table in this specification can be defined as “Mandatory” (M), “Optional” (O), “Excluded” (X), or “Conditional” (C.n). Conditional statements (C.n) are listed directly below the table in which they appear.

1.2.2. Indicating a cell that has no value or content

Where a cell in a table indicates an intended absence of a value or other content, the cell will contain “none” or a hyphen (i.e., a “minus” sign). Examples of this are:

In the “condition” column of the description of a finite state machine where a rule is unconditional
In the “action” column of the description of a finite state machine where a rule has no action
In a “restrictions” column where there are no applicable restrictions
In an interface description where there are no parameters of a specific type

An empty cell in a table indicates that there is no useful information that can be placed in that cell. Examples of this are:

In a “comments” column when there is no comment to make in a particular row
In a column specifying properties when the relevant item is reserved for future use (and therefore does not have any properties)
In a “units” column when the relevant item is unitless

1.3. Architectural concepts

This specification is based on the concepts of states, bindings, messages, elements, addresses, models, and the publish-subscribe paradigm for message exchange that are defined in the Mesh Profile v1.0.1 [1] and Mesh Protocol v1.1 specifications [2].

Note

Note: The Mesh Profile specification was renamed after v1.0.1. Starting with v1.1, the Mesh Profile specification is known as the “Mesh Protocol” specification.

The Mesh Binary Large Object Transfer Model specification introduces the Unknown state value (Section 1.3.1) and the internal state (Section 1.3.2).

1.3.1. Unknown state value

The value Unknown is a special value that is not sent in messages. An Unknown state value represents a state value that is not set, and the internal representation of this state value is implementation specific. For example, in the BLOB Transfer models, the BLOB ID state is Unknown before a BLOB transfer is started.

1.3.2. Internal state

An internal state is a state that is not accessible on the network interface; there are no messages to get or set the value. The representation of the state value may be defined by this specification.

1.4. Error handling

When a model processes an incoming message, the defined behavior may require the model to check one or more error conditions from a table of conditions (for example, see Table 5.9). These error conditions shall be checked in order, from top to bottom, starting from the first row of the table. The model shall stop checking after encountering a failed condition. Or, after not encountering a failed condition, the model shall stop checking after finishing the last row in the table.

1.5. Bluetooth specification release compatibility

This specification is compatible with Mesh Profile v1.0.1 [1] and Mesh Protocol v1.1 [2].

1.6. Conformance

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.

1.7. Terminology

Table 1.2 lists all of the defined terms used in this specification.

Term	Definition Location
BLOB transfer	Section 2
block	Section 2.1
chunk	Section 2.1
internal state	Section 1.3.2
Pull BLOB Transfer mode	Section 2.1
Push BLOB Transfer mode	Section 2.1
Unknown state value	Section 1.3.1

Table 1.2. Terminology

2. BLOB transfer introduction

This specification defines mesh models capable of transferring binary large objects, called BLOBs, over a Bluetooth mesh network. The BLOB Transfer Server model and BLOB Transfer Client model are used to transport data for a higher-layer application.

BLOB transfer is the process of sending a BLOB from a BLOB Transfer Client model to one or more BLOB Transfer Server models. BLOB transfer is able to transfer data objects that are much larger than the maximum Access Layer PDU size. BLOB transfer supports multicasting of the BLOB to many nodes simultaneously.

2.1. BLOB transfer process overview

A higher-layer model or application provides to the BLOB Transfer Client the following:

The list of BLOB Transfer Servers to receive the BLOB.
The multicast address to use for the BLOB transfer.
The application key index to use for the BLOB Transfer.
The time to live (TTL) value that the client uses when it sends messages to the servers.
The BLOB ID of the BLOB being transferred.
The binary data to be transferred (i.e., the BLOB).
The selected transfer mode.
The timeout for the BLOB transfer.

Using these values as inputs, the BLOB Transfer Client starts the Transfer BLOB procedure.

Before a BLOB Transfer Client starts the BLOB transfer, the client optionally checks whether the BLOB Transfer Servers are ready to accept a new BLOB using the Determine Transfer Status procedure. The client also optionally retrieves the transfer capabilities of the servers using the Retrieve Capabilities procedure.

The client breaks each BLOB into suitably sized blocks (based on the capabilities of the servers) and transfers these blocks to the servers. To begin transferring a block, the client starts the Send Block sub-procedure.

Each block is composed of identically sized chunks of data, except for the last chunk which may be smaller than the other chunks if the block’s size is not an integer multiple of the chunk’s size.

There are two distinct ways of transferring the chunks: the Push BLOB Transfer mode and the Pull BLOB Transfer mode. In the Push BLOB Transfer mode the client controls the flow of chunks to the servers, sending all the chunks from a block, then queries the servers to determine which chunks were received. All missing chunks are retransmitted. In the Pull BLOB Transfer mode the server requests chunks from the client as it is able to process them, and the flow of chunks is controlled by the server. The Pull BLOB Transfer mode is typically used to transfer a BLOB to a Low Power node (LPN).

A higher-layer application can determine the percentage of the BLOB that has been transferred using the Get Transfer Progress procedure or can determine the status of the transfer using the Get BLOB Receiver procedure.

A higher-layer application can cancel the BLOB Transfer at any time using the Cancel Transfer procedure.

Push BLOB Transfer. In the Push BLOB Transfer mode, the client starts the Send Data sub-procedure to transfer the chunks from a block to the servers. Chunks are sent using either the unicast addresses of the servers or a multicast address.

Note

Note: The multicast address can be either a group address or a virtual address.

During the block transfer, the client can check the status of the block delivery and get a list of missing chunks by starting the Determine Block Status sub-procedure.

After gathering a list of missing chunks, the client analyzes the information and transfers each missing chunk to the servers. The missing chunks can be transferred using a multicast address or unicast address for each server receiving the block. The use of the unicast addresses or a multicast address during a BLOB transfer is an implementation-specific behavior that the BLOB Transfer Client can determine at run-time.

Pull BLOB Transfer. In the Pull BLOB Transfer mode, the client receives the initial list of chunks the server expects when the Send Block sub-procedure starts. The client transmits the chunks from the initial list to the server. When the server is ready to receive more chunks, or when a timer expires, the server sends a BLOB Partial Block Report to the client to request the next set of chunks. The client then transmits the requested chunks to the server.

3. BLOB Transfer states

3.1. States used by both BLOB Transfer models

This section describes the states used by both the BLOB Transfer Client model and the BLOB Transfer Server model.

The mathematical functions used in this section are defined in Appendix A: Mathematical functions.Appendix A: Mathematical functions

3.1.1. BLOB

The BLOB state is a composite state that identifies and characterizes a BLOB that is being transferred.

The BLOB state includes the following states:

BLOB ID state (see Section 3.1.1.1)
BLOB Size state (see Section 3.1.1.2)
Block Size Log state (see Section 3.1.1.3)
BLOB Data state (see Section 3.1.1.4)
Total Blocks state (see Section 3.1.1.5)

3.1.1.1. BLOB ID

The BLOB ID state is an 8-octet value that uniquely identifies a BLOB on a network. The default value of this state shall be Unknown.

3.1.1.2. BLOB Size

The BLOB Size state is a uint32 value that indicates the size of the BLOB in octets. The default value of this state shall be Unknown. The value 0 is Prohibited.

3.1.1.3. Block Size Log

The Block Size Log state is a uint8 value that is used to calculate the size of the block used in the transfer. The state values are defined in Table 3.1.

Value	Description
0x00–0x05	Prohibited
0x06–0x20	Block Size Log state value
0x21–0xFF	Prohibited

Table 3.1. Block Size Log state values

The default value of Block Size Log state shall be Unknown.

The size of the block in octets (Block Size) shall be calculated from the Block Size Log state using the following formula:

Equation 0.

{Block Size=2}^{B l o c k S i z e L o g}

The last block may be smaller than the Block Size value indicates.

3.1.1.4. BLOB Data

The BLOB Data state is an internal state that is used to store the binary data. The format of the BLOB Data state is implementation specific.

3.1.1.5. Total Blocks

The Total Blocks state is an internal state that indicates the total number of blocks the BLOB is divided into. The Total Blocks state is calculated using the formula:

Equation 0.

Total Blocks=ceil(\frac{BLOB Size}{2^{Block Size Log}})

3.1.2. BLOB Block

The BLOB Block state is a composite state that identifies a block that is being transferred. The BLOB Block state includes the following states:

Block Number state (see Section 3.1.2.1)
Current Block Size state (see Section 3.1.2.2)
Chunk Size state (see Section 3.1.2.3)
Total Chunks state (see Section 3.1.2.4)
BLOB Block Data state (see Section 3.1.2.5)

3.1.2.1. Block Number

The Block Number state is a uint16 value that identifies the number of a specific block within the set of blocks that comprise the BLOB. The state values are defined in Table 3.2. The default value of this state shall be 0xFFFF.

Value	Description
0x0000	The Block Number of the first block from the BLOB.
0x0001	The Block Number of the second block from the BLOB.
…	…
0xFFFE	The Block Number of the last possible block from the BLOB.
0xFFFF	Indicates the Block Number has not been set.

Table 3.2. Block Number state values

3.1.2.2. Current Block Size

The Current Block Size state is an internal state that indicates the size of the current block, which is the block being transferred. The format of the Current Block Size state is implementation specific.

3.1.2.3. Chunk Size

The Chunk Size state is a uint16 value that indicates the chunk size in octets for a specific block within the set of blocks that comprise the BLOB. The state values are defined in Table 3.3. The default value of this state shall be 0xFFFF.

Value	Description
0x0000	Prohibited
0x0001–0xFFFE	Size of chunk in octets
0xFFFF	Indicates the Chunk Size has not been set.

Table 3.3. Chunk Size state values

3.1.2.4. Total Chunks

The Total Chunks state is an internal state that indicates the number of chunks in a specific block within the set of blocks that comprise the BLOB. The format of the Total Chunks state is implementation specific.

3.1.2.5. BLOB Block Data

The BLOB Block Data state is an internal state that stores the binary data contained within a specific block within the set of blocks that comprise the BLOB. The format of the BLOB Block Data state is implementation specific.

3.1.3. Transfer TTL

The Transfer TTL state is a uint8 value that indicates the TTL value to use when originating a Network PDU from the BLOB Transfer Client or BLOB Transfer Server model.

The Transfer TTL state values are defined in Table 3.4.

Value	Description
0x00	TTL field value of a Network PDU.
0x01	Prohibited
0x02–0x7F	TTL field value of a Network PDU.
0x80–0xFE	Prohibited
0xFF	TTL field value of a Network PDU is the Default TTL state value.

Table 3.4. Transfer TTL state values

The default value of the Transfer TTL state shall be 0xFF.

3.1.4. Transfer Mode

The Transfer Mode state is a 2-bit value that indicates the mode of the BLOB transfer.

The values for the Transfer Mode state are defined in Table 3.5.

Value	Description
0x00	No Active Transfer
0x01	Push BLOB Transfer mode (see Section 5.2.5)
0x02	Pull BLOB Transfer mode (see Section 5.2.4)
0x03	RFU

Table 3.5. Transfer Mode state values

3.1.4.1. Binding with the Transfer Phase state

The Transfer Mode state is bound to an instance of the Transfer Phase state (see Section 3.2.1) when the Transfer Mode state is present on a BLOB Transfer Server model. Otherwise, the Transfer Mode state is not bound.

When the Transfer Phase state is Waiting For Transfer Start or is Inactive, the Transfer Mode state shall be set to No Active Transfer.

3.2. BLOB Transfer Server states

This section describes the states used by the BLOB Transfer Server model only.

3.2.1. Transfer Phase

The Transfer Phase state is a uint8 value that identifies the phase of the BLOB Transfer Server. The values for this state are defined in Table 3.6. The default value of this state shall be Inactive.

Status code	Enumeration	Description
0x00	Inactive	The BLOB Transfer Server is awaiting configuration and cannot receive a BLOB.
0x01	Waiting For Transfer Start	The BLOB Transfer Server is ready to receive the BLOB identified by the Expected BLOB ID.
0x02	Waiting For Next Block	The BLOB Transfer Server is waiting for the next block of data.
0x03	Waiting For Next Chunk	The BLOB Transfer Server is waiting for the next chunk of data.
0x04	Complete	The BLOB was transferred successfully.
0x05	Suspended	The Initialize And Receive BLOB procedure is paused.
0x06–0xFF	–	RFU

Table 3.6. Transfer Phase state values

3.2.2. Expected BLOB ID

The Expected BLOB ID state is an 8-octet value that identifies the BLOB ID of a BLOB that the BLOB Transfer Server expects to receive. This value is provided by a higher-layer model or application to link this higher-layer model or application to a BLOB transfer. The default value of this state shall be Unknown.

3.2.3. Blocks Not Received

The Blocks Not Received state indicates the blocks that the server has not yet received.

The Blocks Not Received state size (in bits) is calculated using the following formula:

Equation 0.

Size of Blocks Not Received=ceil (\frac{Total Blocks}{8}) ×8

For each block in the transfer, bit N shall equal 1 if the block identified by Block Number N has not been received. For each received block, the corresponding bit shall equal 0. All other bits, if any, shall equal 0.

The default value of this state shall indicate that no block has been received.

3.2.4. Missing Chunks

The Missing Chunks state indicates the chunks that the server has not yet received for the block that is being transferred.

The Missing Chunks state size (in bits) is calculated using the following formula:

Equation 0.

Size of Missing Chunks=ceil (\frac{Total Chunks}{8}) ×8

For each chunk in the block, bit N shall equal 1 if the chunk identified by Chunk Number N has not been received. For each received chunk, the corresponding bit shall equal 0. All other bits, if any, shall equal 0.

The default value of this state shall indicate that no chunk has been received.

For example, if the Total Chunks value is 10, the Missing Chunks state size is 2 octets. Then, if chunks with Chunk Numbers 1 to 7 and 9 have been received, the Missing Chunks state value is 0000000100000001b.

3.2.5. Client MTU Size

The Client MTU Size state is a uint16 value that indicates the maximum transmission unit (MTU) size for the client that initiated the BLOB transfer. The values for this state are defined in Table 3.7. The default value of this state shall be Unknown.

Value	Description
0x0000–0x0013	Prohibited
0x0014–0xFFFF	Maximum size of the transport unit supported by the client

Table 3.7. Client MTU Size state values

3.2.6. Server Timeout Base

The Server Timeout Base state is a uint16 value that is used to compute the time the server waits for messages from the client in the Waiting For Next Chunk phase or Waiting For Next Block phase. The default value of this state shall be Unknown.

3.2.7. Capabilities

The Capabilities state is a composite state that indicates the transfer capabilities of the BLOB Transfer Server model instance. The values of the Capabilities state are implementation specific and may change while the Transfer Phase state is Inactive and shall not change while the Transfer Phase is in any other state. The Capabilities state includes the following states:

Min Block Size Log state (see Section 3.2.7.1)
Max Block Size Log state (see Section 3.2.7.2)
Max Total Chunks state (see Section 3.2.7.3)
Max Chunk Size state (see Section 3.2.7.4)
Max BLOB Size state (see Section 3.2.7.5)
Server MTU Size state (see Section 3.2.7.6)
Supported Transfer Mode state (see Section 3.2.7.7)

3.2.7.1. Min Block Size Log

The Min Block Size Log state is a uint8 value that represents the minimum acceptable block size in octets that the server can receive. The Min Block Size Log state is the binary logarithm of the minimum acceptable block size. The state values are defined in Table 3.8.

Value	Description
0x00–0x05	Prohibited
0x06–0x20	Minimum Block Size Log state value
0x21–0xFF	Prohibited

Table 3.8. Min Block Size Log state values

The Min Block Size Log state value is calculated using the following formula:

Equation 0.

Min Block Size Log=ceil {(log}_{2} (minimum acceptable block size))

The last block might be smaller than this value indicates.

3.2.7.2. Max Block Size Log

The Max Block Size Log state is a uint8 value that represents the maximum acceptable block size in octets that the server can receive. The Max Block Size Log state is the binary logarithm of the maximum acceptable block size. The Max Block Size Log state value shall be equal to or greater than the Min Block Size Log state value. The state values are defined in Table 3.9.

Value	Description
0x00–0x05	Prohibited
0x06–0x20	Maximum Block Size Log state values
0x21–0xFF	Prohibited

Table 3.9. Max Block Size Log values

The Max Block Size Log state value is calculated using the following formula:

Equation 0.

Max Block Size Log=ceil ({log}_{2} (maximum acceptable block size))

3.2.7.3. Max Total Chunks

The Max Total Chunks state is a uint16 value that indicates the maximum number of chunks that a block can be divided into. The state values are defined in Table 3.10.

Value	Description
0x0000	Prohibited
0x0001–0xFFFF	Maximum number of chunks in a block

Table 3.10. Max Total Chunks values

3.2.7.4. Max Chunk Size

The Max Chunk Size state is a uint16 value that indicates the maximum size of a chunk in octets that the server supports. The state values are defined in Table 3.11.

Value	Description
0x0000–0x0007	Prohibited
0x0008–0xFFFE	Maximum size of a chunk
0xFFFF	Prohibited

Table 3.11. Max Chunk Size state values

3.2.7.5. Max BLOB Size

The Max BLOB Size state is a uint32 value that indicates the maximum size of a BLOB in octets that the server can receive. The state values are defined in Table 3.12.

Value	Description
0x00000000	Prohibited
0x00000001–0xFFFFFFFF	Maximum size of a BLOB

Table 3.12. Max BLOB Size state values

3.2.7.6. Server MTU Size

The Server MTU Size state is a uint16 value that indicates the MTU size in octets that the server can support. The state values are defined in Table 3.13.

Value	Description
0x0000–0x0013	Prohibited
0x0014–0xFFFF	Maximum size of the transport unit supported by the server

Table 3.13. Server MTU Size state values

3.2.7.7. Supported Transfer Mode

The Supported Transfer Mode state is an 8-bit field value that indicates the transfer modes supported by the server. The state values are defined in Table 3.14.

Bit	Description
0	Push BLOB Transfer mode bit
1	Pull BLOB Transfer mode bit
2-7	Reserved For Future Use

Table 3.14. Supported Transfer Mode state values

If the Push BLOB Transfer mode is supported, then the value of bit 0 shall be set to 1. Otherwise, the value of the bit shall be set to 0.

If the Pull BLOB Transfer mode is supported, then the value of bit 1 shall be set to 1. Otherwise, the value of the bit shall be set to 0.

At least one of the bits that are not Reserved For Future Use shall be set to 1.

3.3. BLOB Transfer Client states

This section describes the states that are used by the BLOB Transfer Client model in addition to the states used by both the BLOB Transfer Client model and the BLOB Transfer Server model.

3.3.1. BLOB Receivers

The BLOB Receivers state is an internal state that stores a list of BLOB Transfer Servers that are participating in the transfer. Each list entry indicates the status of the transfer to the server. The list entries have the format defined in Table 3.15. The default value of this state shall be empty.

Field	Description
Address	Unicast address of the server
Retrieved Transfer Phase	Retrieved transfer phase of the server
Status	Status of the last operation
Blocks Not Received	Indicates which blocks were not received by the server.
Missing Chunks	Indicates which chunks were not received by the server in the current block.

Table 3.15. Format of the BLOB Receivers state entry

The Address field indicates a unicast address of the BLOB Transfer Server.

The Retrieved Transfer Phase field indicates the retrieved transfer phase of the BLOB Transfer Server identified by the Address field. The format of the Retrieved Transfer Phase field is defined in Table 3.16. The default value of this field shall be Unknown.

Status code	Enumeration	Description
0x00	Inactive	The BLOB Transfer Server is awaiting configuration and cannot receive a BLOB.
0x01	Waiting For Transfer Start	The BLOB Transfer Server is ready to receive the BLOB identified by the Expected BLOB ID.
0x02	Waiting For Next Block	The BLOB Transfer Server is waiting for the next block of data.
0x03	Waiting For Next Chunk	The BLOB Transfer Server is waiting for the next chunk of data.
0x04	Complete	The BLOB was transferred successfully.
0x05	Suspended	The Initialize And Receive BLOB procedure is paused.
0x06	Unknown	The Transfer Phase state is unavailable to the client.
0x07–0xFF	–	RFU

Table 3.16. Retrieved Transfer Phase field values

The Status field indicates the status of the last operation with the server. The default value of this field shall be Success.

The Blocks Not Received field indicates the blocks that the server has not received. The default value of this field shall indicate that no block has been received.

The Missing Chunks field indicates the chunks that are missing in the block that is being transferred. The default value of this field shall indicate that no chunk has been received.

3.3.2. Active BLOB Receivers

The Active BLOB Receivers state is an internal state that stores a list of BLOB Transfer Servers that are actively participating in the transfer (e.g., are not timed out). Each list entry indicates the status of the transfer to the server. The internal representation of this state is implementation specific. The default value of this state shall be empty.

3.3.3. BLOB Receivers Capabilities

The BLOB Receivers Capabilities state is an internal state that stores a list of BLOB Transfer Servers that are participating in the transfer. Each list entry indicates the Capabilities state (see Section 3.2.7). The internal representation of this state is implementation specific.

3.3.4. BLOB Multicast Address

The BLOB Multicast Address state is an internal state that contains a group address, the Label UUID of a virtual address, or the Unassigned address. If the value of this state is a group address or a virtual address, then the client sends messages to the BLOB Transfer Servers at that address.

If the value of the BLOB Multicast Address state is the Unassigned address, then messages are not sent to a multicast address. The default value of this state shall be the Unassigned address.

3.3.5. AppKey Index

The AppKey Index state is a uint16 value that indicates the index of the application key that the client shall use to exchange messages with the BLOB Transfer Server. The default value of this state shall be Unknown.

3.3.6. Client Timeout Base

The Client Timeout Base state is a uint16 value that is used to compute the time to wait for messages from the server, after which the client considers a server to be timed out. The default value of this state is implementation specific.

3.4. Summary of status codes

Table 3.17 defines the status codes used in BLOB Transfer messages that contain a status field.

Status code (4 bits)	Status Code Name	Description
0x00	Success	The message was processed successfully.
0x01	Invalid Block Number	The Block Number field value is not within the range of blocks being transferred.
0x02	Invalid Block Size	The block size is smaller than the size indicated by the Min Block Size Log state or is larger than the size indicated by the Max Block Size Log state.
0x03	Invalid Chunk Size	The chunk size exceeds the size indicated by the Max Chunk Size state, or the number of chunks exceeds the number specified by the Max Total Chunks state.
0x04	Wrong Phase	The operation cannot be performed while the server is in the current phase.
0x05	Invalid Parameter	A parameter value in the message cannot be accepted.
0x06	Wrong BLOB ID	The message contains a BLOB ID value that is not expected.
0x07	BLOB Too Large	There is not enough space available in memory to receive the BLOB.
0x08	Unsupported Transfer Mode	The transfer mode is not supported by the BLOB Transfer Server model.
0x09	Internal Error	An internal error occurred on the node.
0xA	Information Unavailable	The requested information cannot be provided while the server is in the current phase.
0xB–0xF	RFU	Reserved for Future Use

Table 3.17. Status codes used by the BLOB Transfer Server and the BLOB Transfer Client models

4. BLOB Transfer messages

4.1. BLOB Transfer Get

A BLOB Transfer Get message is an acknowledged message used to get the state of a BLOB transfer, if any, on a BLOB Transfer Server.

The response to a BLOB Transfer Get message is a BLOB Transfer Status message.

The structure of the message is defined in Table 4.1.

Field	Size (octets)	Description	Req.
Opcode	2	The message opcode	M

Table 4.1. BLOB Transfer Get message structure

The Opcode field shall contain the opcode value for the BLOB Transfer Get message defined in the Assigned Numbers document [3].

4.2. BLOB Transfer Start

A BLOB Transfer Start message is an acknowledged message used to start a new BLOB transfer.

The response to a BLOB Transfer Start message is a BLOB Transfer Status message.

The structure of the BLOB Transfer Start message is defined in Table 4.2.

Field	Size (bits)	Description	Req.
Opcode	16	The message opcode	M
RFU	6	Reserved for Future Use	M
Transfer Mode	2	BLOB transfer mode	M
BLOB ID	64	BLOB identifier	M
BLOB Size	32	BLOB size in octets	M
Block Size Log	8	Indicates the block size	M
Client MTU Size	16	MTU size supported by the client	M

Table 4.2. BLOB Transfer Start message structure

The Opcode field shall contain the opcode value for the BLOB Transfer Start message defined in the Assigned Numbers document [3].

The Transfer Mode field shall indicate the new value of the Transfer Mode state (see Section 3.1.4). The valid values of the field are Pull BLOB Transfer mode and Push BLOB Transfer mode.

The BLOB ID field shall indicate the ID of the BLOB that is to be transferred.

The BLOB Size field shall indicate the size of the BLOB to be transferred.

The Block Size Log field shall indicate the new value of the Block Size Log state to be used in the transfer (see Section 3.1.1.3).

The Client MTU Size field shall indicate the new value of the Client MTU Size state (see Section 3.2.5).

4.3. BLOB Transfer Cancel

A BLOB Transfer Cancel message is an acknowledged message used to cancel the ongoing BLOB transfer.

The response to the BLOB Transfer Cancel message is a BLOB Transfer Status message.

The structure of the BLOB Transfer Cancel message is defined in Table 4.3.

Field	Size (octets)	Description	Req.
Opcode	2	The message opcode	M
BLOB ID	8	BLOB identifier	M

Table 4.3. BLOB Transfer Cancel message structure

The Opcode field shall contain the opcode value for the BLOB Transfer Cancel message defined in the Assigned Numbers document [3].

The BLOB ID field shall identify the BLOB whose transfer is to be canceled.

4.4. BLOB Transfer Status

A BLOB Transfer Status message is an unacknowledged message used to report the state of the BLOB Transfer Server.

The message is sent in response to a BLOB Transfer Get message, a BLOB Transfer Start message, or a BLOB Transfer Cancel message.

The structure of the BLOB Transfer Status message is defined in Table 4.4.

Field	Size (bits)	Description	Req.
Opcode	16	The message opcode	M
Status	4	Status Code for the requesting message	M
RFU	2	Reserved for Future Use	M
Transfer Mode	2	BLOB transfer mode	M
Transfer Phase	8	Transfer phase	M
BLOB ID	64	BLOB identifier	O
BLOB Size	32	BLOB size in octets	C.1
Block Size Log	8	Indicates the block size	C.2
Transfer MTU Size	16	MTU size in octets	C.2
Blocks Not Received	variable	Bit field indicating blocks that were not received	C.2

Table 4.4. BLOB Transfer Status message structure

C.1:: If the BLOB ID field is present, then the BLOB Size field may be present; otherwise, the BLOB Size field shall not be present.
C.2:: If the BLOB Size field is present, then the Block Size Log, Transfer MTU Size, and Blocks Not Received fields shall be present; otherwise, the Block Size Log, Transfer MTU Size, and Blocks Not Received fields shall not be present.

The Opcode field shall contain the opcode value for the BLOB Transfer Status message defined in the Assigned Numbers document [3].

The Status field shall identify the Status Code for the last operation performed on the BLOB Transfer Server states. The values of the Status field are defined in Table 3.17.

The Transfer Mode field shall indicate the Transfer Mode state of the BLOB Transfer Server (see Section 3.1.4).

The Transfer Phase field shall indicate the Transfer Phase state (see Section 3.2.1).

If present, the BLOB ID field shall indicate the Expected BLOB ID state (see Section 3.2.2).

If present, the BLOB Size field shall indicate the BLOB Size state of the BLOB Transfer Server (see Section 3.1.1.2).

If present, the Block Size Log field shall indicate the Block Size Log state of the BLOB Transfer Server (see Section 3.1.1.3).

If present, the Transfer MTU Size shall indicate the calculated Transfer MTU size value (see Section 5.3.2).

If present, the Blocks Not Received field shall indicate the Blocks Not Received state (see Section 3.2.3).

4.5. BLOB Block Get

A BLOB Block Get message is an acknowledged message used to retrieve the phase of the transfer and to find out which block, if any, is active (i.e., being transferred) and get the status of that block.

The response to the BLOB Block Get message is a BLOB Block Status message.

The structure of the message is defined in Table 4.5.

Field	Size (octets)	Description	Req.
Opcode	2	The message opcode	M

Table 4.5. BLOB Block Get message structure

The Opcode field shall contain the opcode value for the BLOB Block Get message defined in the Assigned Numbers document [3].

4.6. BLOB Block Start

A BLOB Block Start message is an acknowledged message used to start the transfer of an incoming block to the server.

The response to the BLOB Block Start message is a BLOB Block Status message.

The structure of the BLOB Block Start message is defined in Table 4.6.

Field	Size (octets)	Description	Req.
Opcode	2	The message opcode	M
Block Number	2	Block number of the incoming block	M
Chunk Size	2	Chunk size (in octets) for the incoming block	M

Table 4.6. BLOB Block Start message structure

The Opcode field shall contain the opcode value for the BLOB Block Start message defined in the Assigned Numbers document [3].

The Block Number field shall indicate the new value of the Block Number state (see Section 3.1.2.1).

The Chunk Size field shall indicate the new value of the Chunk Size state (see Section 3.1.2.3).

4.7. BLOB Block Status

A BLOB Block Status message is an unacknowledged message used to report the status of the active block (i.e., the block being transferred), if any.

The BLOB Block Status message is sent as a response to the BLOB Block Start message or the BLOB Block Get message.

The structure of the BLOB Block Status message is defined in Table 4.7.

Field	Size (bits)	Description	Req.
Opcode	8	The message opcode	M
Status	4	Status Code for the requesting message	M
RFU	2	Reserved for Future Use	M
Format	2	Indicates the format used to report missing chunks	M
Block Number	16	Block number of the current block	M
Chunk Size	16	Chunk Size (in octets) for the current block	M
Missing Chunks	variable	Bit field of missing chunks for this block	C.1
Encoded Missing Chunks	variable	List of chunks requested by the server	C.2

Table 4.7. BLOB Block Status message structure

C.1:: If the Format field is set to Some Chunks Missing, then the Missing Chunks field shall be present; otherwise, the Missing Chunks field shall not be present.
C.2:: If the Format field is set to Encoded Missing Chunks, then the Encoded Missing Chunks field may be present; otherwise, the Encoded Missing Chunks field shall not be present.

The Opcode field shall contain the opcode value for the BLOB Block Status message defined in the Assigned Numbers document [3].

The Status field shall identify the Status Code for the last operation performed on the BLOB Transfer Server states. The values of the Status field are defined in Table 3.17.

The Format field defines how missing chunks are reported. The values of the Format field are defined in Table 4.8.

Format	Enumeration	Description
0x0	All Chunks Missing	All chunks in the block are missing.
0x1	No Missing Chunks	All chunks in the block have been received.
0x2	Some Chunks Missing	At least one chunk has been received and at least one chunk is missing.
0x3	Encoded Missing Chunks	List of chunks requested by the server

Table 4.8. Format field enumeration values

The Block Number field shall indicate the Block Number state (see Section 3.1.2.1).

The Chunk Size field shall indicate the Chunk Size state (see Section 3.1.2.2).

If present, the Missing Chunks field shall indicate the Missing Chunks state.

If present, the Encoded Missing Chunks field shall indicate the list of the chunks requested by the BLOB Transfer Server. Each chunk is identified by a uint16 Chunk Number. The list of the Chunk Numbers is encoded as defined in Table 4.9.

Table 4.9 defines the encoding between the uint16 number and the array of octets of variable size. To encode a value, the Value Range column shall be checked, and if the value is within the defined range a corresponding row is selected. The "x", "y", and "z" symbols define bit groups. When the row is selected, the bit groups' values shall be identified using the Value Bits column. The encoded value is an array of up to three octets defined in the First Octet, Second Octet, and Third Octet columns in the selected row. The bit groups' values of the First Octet, Second Octet, and Third Octet columns shall be substituted using the bit group values of the corresponding bit groups identified in the Value Bits column.

Value Range	Value Bits	First Octet	Second Octet	Third Octet
0x0-0x7F	00000000 0xxxxxxx	0xxxxxxx	–	–
0x80-0x7FF	00000yyy yyxxxxxx	110yyyyy	10xxxxxx	–
0x800-0xFFFF	zzzzyyyy yyxxxxxx	1110zzzz	10yyyyyy	10xxxxxx

Table 4.9. Encoding between the uint16 number and the array of octets

For example, if the requested chunks list is “0x00, 0x10, 0x80, 0x100”, the value of the Encoded Missing Chunks field is “0x00, 0x10, 0xC2, 0x80, 0xC4, 0x80”.

4.8. BLOB Partial Block Report

A BLOB Partial Block Report message is an unacknowledged message used by the BLOB Transfer Server to request chunks.

The structure of the BLOB Partial Block Report message is defined in Table 4.10.

Field	Size (bits)	Description	Req.
Opcode	8	The message opcode	M
Encoded Missing Chunks	variable	List of chunks requested by the server	O

Table 4.10. BLOB Partial Block Report message structure

The Opcode field shall contain the opcode value for the BLOB Partial Block Report message defined in the Assigned Numbers document [3].

4.9. BLOB Chunk Transfer

A BLOB Chunk Transfer message is an unacknowledged message used to deliver a chunk of the current block to a BLOB Transfer Server.

The structure of the BLOB Chunk Transfer message is defined in Table 4.11.

Field	Size (octets)	Description	Req.
Opcode	1	The message opcode	M
Chunk Number	2	The chunk’s number in a set of chunks in a block	M
Chunk Data	variable	Binary data from the current block	M

Table 4.11. BLOB Chunk Transfer message structure

The Opcode field shall contain the opcode value for the BLOB Chunk Transfer message defined in the Assigned Numbers document [3].

The Chunk Number field shall indicate the chunk’s number in a set of chunks in a block.

The Chunk Data field shall contain the chunk of the block identified by the Chunk Number. The size of the Chunk Data field shall be greater than 0 octets, and shall be less than or equal to the number of octets indicated by the Chunk Size state.

4.10. BLOB Information Get

A BLOB Information Get message is an acknowledged message used to get the Capabilities state of the BLOB Transfer Server.

The response to the BLOB Information Get message is a BLOB Information Status message.

The structure of the BLOB Information Get message is defined in Table 4.12.

Field	Size (octets)	Description	Req.
Opcode	2	The message opcode	M

Table 4.12. BLOB Information Get message structure

The Opcode field shall contain the opcode value for the BLOB Information Get message defined in the Assigned Numbers document [3].

4.11. BLOB Information Status

A BLOB Information Status message is an unacknowledged message used to report the Capabilities state of the BLOB Transfer Server.

The BLOB Information Status message is sent as a response to the BLOB Information Get message.

The structure of the BLOB Information Status message is defined in Table 4.13.

Field	Size (octets)	Description	Req.
Opcode	2	The message opcode	M
Min Block Size Log	1	Minimum block size supported by the server	M
Max Block Size Log	1	Maximum block size supported by the server	M
Max Total Chunks	2	Maximum number of chunks in block supported by the server	M
Max Chunk Size	2	Maximum chunk size supported by the server	M
Max BLOB Size	4	Maximum BLOB size supported by the server	M
Server MTU Size	2	MTU size supported by the server	M
Supported Transfer Mode	1	BLOB transfer modes supported by the server	M

Table 4.13. BLOB Information Status message structure

The Opcode field shall contain the opcode value for the BLOB Information Status message defined in the Assigned Numbers document [3].

The Min Block Size Log field shall indicate the Min Block Size Log state (see Section 3.2.7.1).

The Max Block Size Log field shall indicate the Max Block Size Log state (see Section 3.2.7.2).

The Max Total Chunks field shall indicate the Max Total Chunks state (see Section 3.2.7.3).

The Max Chunk Size field shall indicate the Max Chunk Size state (see Section 3.2.7.4).

The Max BLOB Size field shall indicate the Max BLOB Size state (see Section 3.2.7.5).

The Server MTU Size field shall indicate the Server MTU Size state (see Section 3.2.7.6).

The Supported Transfer Mode field shall indicate the Supported Transfer Mode state (see Section 3.2.7.7).

5. BLOB Transfer Server model

5.1. Description

The BLOB Transfer Server model is used to receive a BLOB from a BLOB Transfer Client. The BLOB is delivered to a higher-layer application for further processing after the transfer is complete.

The BLOB Transfer Server is a root model (i.e., it does not extend any other models).

This model shall support model subscription, as defined in Section 4.2.3 of Mesh Profile v1.0.1 [1] and Section 4.2.4 of Mesh Protocol v1.1 [2].

The access layer security on the BLOB Transfer Server model uses application keys.

When the BLOB Transfer Server model is implemented on an LPN, and the BLOB Pull State Machine is instantiated, then the LPN shall poll the Friend node at least every T_MBPI (see Section 5.2.4). Additionally, an LPN that instantiates the BLOB Transfer Server model should send a Friend Poll message to the Friend node at least one time per hour. The more frequently an LPN sends a Friend Poll message, the more quickly the BLOB Pull State Machine is instantiated (see Section 5.2.4).

The BLOB Transfer Server model defines the state instances listed in Table 5.1 and Table 5.2 and the messages listed in Table 5.3, and requires one element: the BLOB Transfer Main element. The BLOB Transfer Main element contains the BLOB Transfer Server main model.

Table 5.1 defines the states that are stored with a scene from the BLOB Transfer Server model.

State	Stored with Scene
BLOB	No
BLOB Block	No
Transfer TTL	No
Transfer Mode	No
Transfer Phase	No
Capabilities	No
Expected BLOB ID	No
Blocks Not Received	No
Missing Chunks	No
Client MTU Size	No
Server Timeout Base	No

Table 5.1. BLOB Transfer Server states that are stored with a scene

Table 5.2 illustrates the state bindings between the BLOB Transfer Server model states and the states of the models that the BLOB Transfer Server extends.

State	Bound State
State	Model	State
BLOB	–	–
BLOB Block	–	–
Transfer TTL	–	–
Transfer Mode	BLOB Transfer Server	Transfer Phase
Transfer Phase	–	–
Capabilities	–	–
Expected BLOB ID	–	–
Blocks Not Received	–	–
Missing Chunks	–	–
Client MTU Size	–	–
Server Timeout Base	–	–

Table 5.2. BLOB Transfer Server states and bindings

Table 5.3 lists the BLOB Transfer Server model messages.

Element	Model Name	State	Message	Rx	Tx
BLOB Transfer Main	BLOB Transfer Server	Transfer Phase, Expected BLOB ID, Blocks Not Received, Client MTU Size, Server Timeout Base, BLOB, Transfer Mode, Transfer TTL, Capabilities	BLOB Transfer Get	M	–
			BLOB Transfer Start	M	–
			BLOB Transfer Cancel	M	–
			BLOB Transfer Status	–	M
		Transfer Phase, Blocks Not Received, BLOB Block, Missing Chunks	BLOB Block Get	M	–
			BLOB Block Start	M	–
			BLOB Partial Block Report	–	O
			BLOB Block Status	–	M
		Transfer Phase, Missing Chunks, BLOB Block, BLOB	BLOB Chunk Transfer	M	–
		Capabilities	BLOB Information Get	M	–
		Capabilities	BLOB Information Status	–	M

Table 5.3. BLOB Transfer Server messages

5.2. Procedures

5.2.1. Initialize And Receive BLOB procedure

The Initialize And Receive BLOB procedure is executed on a BLOB Transfer Server to prepare the server to accept a BLOB, and to receive a BLOB from a BLOB Transfer Client.

As input, the procedure takes a BLOB ID, a Timeout, and a Transfer TTL.

When the procedure is started, and the Transfer Phase state is not Inactive, Suspended, or Complete, then the procedure fails.

When the procedure is started, and the Transfer Phase state is either Inactive, Suspended, or Complete, then the server shall set the following states:

The BLOB Data state and the BLOB Block Data state shall be cleared.
The Expected BLOB ID state shall be set to the value of the BLOB ID input.
The Server Timeout Base state shall be set to the value of the Timeout input.
The Transfer TTL state shall be set to the value of the Transfer TTL input.
The Transfer Phase state shall be set to Waiting For Transfer Start.
The Block Number state shall be set to 0xFFFF.
The Chunk Size state shall be set to 0xFFFF.

Then, the server waits to receive the BLOB Transfer Start message to begin the BLOB transfer (see Section 5.3.2). The Receive BLOB Timeout timer does not run until the BLOB Transfer Start message is received. The server processes BLOB Block Start messages (see Section 5.3.6) and BLOB Chunk Transfer messages (see Section 5.3.9) to receive the BLOB data from the client. As a part of the message processing the server either starts or removes the Receive BLOB Timeout timer as applicable.

When a BLOB Transfer Server model receives any BLOB Transfer messages, and the Receive BLOB Timeout timer is active, then the server shall restart the timer with the initial value (see Section 5.2.4 and Section 5.2.5).

Equation 0.

Receive BLOB Timeout=10×(Server Timeout Base state+1) [seconds]

When the Receive BLOB Timeout timer expires (i.e., the timer value reaches 0), the server shall set the Transfer Phase state to Suspended, shall discard the received chunks from the block, shall set the value of the Missing Chunks state to Unknown, and shall remove the instance of the Pull BLOB State Machine. At that point, the procedure stops, and the higher-layer application or the model is informed that the operation has been stopped.

When the BLOB transfer has completed successfully (i.e., the Transfer Phase state is Complete), the procedure gives the BLOB Data state as output and completes successfully.

The procedure can be canceled at any time by a higher-layer application or the model. When the procedure is canceled, the server shall do the following:

The BLOB Data state and the BLOB Block Data state shall be cleared.
The Expected BLOB ID state, Block Number state, Chunk Size state, BLOB Size state, Block Size Log state, and Client MTU Size state shall be set to their default values.
The Blocks Not Received state shall be set to indicate that no block has been received.
The Missing Chunks state shall be set to indicate that no chunk has been received.
The Transfer Phase state shall be set to Inactive.
The Receive BLOB Timeout timer shall be stopped.
If the Transfer Mode state is Pull BLOB Transfer mode, then the server shall remove the instance of the Pull BLOB State Machine.

5.2.2. Get BLOB Reception Progress procedure

The Get BLOB Reception Progress procedure is executed on a BLOB Transfer Server to report the progress of the current transfer.

The procedure gives the Reception Progress as a percentage as output, which is calculated using the following equation:

Equation 0.

Reception Progress= (\frac{Total Blocks-Number Of Blocks Not Received}{Total Blocks})

Number Of Blocks Not Received represents the number of bits that are set to 1 in the Blocks Not Received state.

5.2.3. Select Missing Chunks procedure

The Select Missing Chunks procedure is executed on a BLOB Transfer Server to select the subset of missing chunks that the server requests from the BLOB Transfer Client in Pull BLOB Transfer mode.

The BLOB Transfer Server shall generate a Requested Chunks List. The Requested Chunks List is a list of selected chunk numbers identified as missing in the Missing Chunks state (see Section 3.2.4). The method the server uses to select chunk numbers is implementation specific. If any chunks are missing from the active block, then the Request Chunks List shall contain at least one chunk number. If no chunks are missing from the active block, then the Requested Chunks List shall be empty.

If the BLOB Transfer Server is an LPN, then the server should select no more chunks than the Friend node can store in its Friend Queue without discarding messages. The number of chunks that the Friend Queue stores depends on the size of the chunk and the size of the Friend Queue. The maximum number of chunks that can fit in the Friend Queue can be estimated using the following equations:

If the Chunk Size is 8 octets or less (i.e., the chunk is not segmented):

Equation 0.

Maximum Number of Chunks=Friend Queue Size

If the Chunk Size is 9 octets or more (i.e., the chunk is segmented):

Equation 0.

Maximum Number of Chunks=floor (\frac{Friend Queue Size×12}{Chunk Size+7})

Note

Note: The actual number of these messages that can be queued depends on how many other nodes are sending messages to the LPN.

As output, the Select Missing Chunks procedure gives a list of chunk numbers for chunks that are missing from the active block and are being requested from the client.

5.2.4. Pull BLOB procedure

When the Pull BLOB Transfer mode is used, the Pull BLOB procedure is used to retrieve the chunks. In this procedure a BLOB Transfer Server uses an instance of the Pull BLOB State Machine to limit the number of chunks sent by a BLOB Transfer Client. For example, on an LPN, the BLOB Transfer Server could use this transfer procedure to manage the Friend Queue ([1] and [2]) and limit the number of chunks retransmitted over the network.

When the BLOB Transfer Server model is instantiated on an LPN, the timing parameters of the BLOB transfer are related to the maximum interval between Friend Poll messages. The maximum interval between Friend Poll messages sent during the BLOB transfer is called the Maximum BLOB Poll Interval. The Maximum BLOB Poll Interval is designated “T_MBPI” and shall be set to 30 seconds. The initial timer value used by an instance of the Pull BLOB State machine is called T_BPI and shall be less than or equal to $T_MBPI+1 [seconds]$ .

The Pull BLOB procedure starts when the Pull BLOB state machine is instantiated in the Initial state. The Pull BLOB procedure completes when the Pull BLOB state machine reaches the Block Reception Failed or All Chunks Received state. The Pull BLOB procedure can be stopped by the higher layer by removing the instance of the Pull BLOB state machine.

The initial value of the Receive BLOB Timeout timer is calculated using the following formula:

Equation 0.

Receive BLOB Timeout=Max(T_BPI×n, 10×(Server Timeout Base state+1)) [seconds]

where, the value of ‘n’ is implementation specific and is greater than or equal to 1, to allow the BLOB Transfer Server to repeat BLOB Partial Block Report messages.

Figure 5.1 illustrates the operation of the Pull BLOB State Machine.

Figure 5.1. Pull BLOB State Machine states, events, event actions, and transitions

Table 5.4 defines the timers used by the Pull BLOB State Machine and the corresponding values of the timers.

Timer Name	Initial Timer Value	Description
New Chunk	T_BPI	The timer defines the interval used in the following contexts: The interval between the instantiation of the Pull BLOB State Machine and reception of the first new chunk The time to wait for the first requested chunk in the BLOB Block Status message
Reception	T_BPI	The timer defines the time to wait for all requested chunks, starting from reception of the first new chunk.
Block Complete	T_BPI	The timer defines the interval used for sending a BLOB Partial Block Report after a Block is complete.

Table 5.4. Pull BLOB State Machine timers

Table 5.5 defines the states of the Pull BLOB State Machine.

State	Description
Initial	Initial state of the Pull BLOB State Machine
Send Partial Block Report	Prepare and send a BLOB Partial Block Report message
Waiting For First Chunk	Waiting for the first BLOB Chunk Transfer message
Chunks Reception	Processing the BLOB Chunk Transfer messages
Check Chunks	Check whether all chunks for the active block have been received
Check The Receive BLOB Timeout Timer	Check whether to resend the previous BLOB Partial Block Report message
All Chunks Received	Block transfer is complete
Block Reception Failed	Block reception failed and transfer is suspended
Check The Receive BLOB Timeout Timer After All Chunks Are Received	Check whether to resend the BLOB Partial Block Report message after all chunks have been received
Stopped	Block reception either completed or suspended

Table 5.5. Pull BLOB State Machine states

Table 5.6 defines the events that determine the state transitions in the Pull BLOB State Machine and the conditions that generate the events. When the Pull BLOB State Machine state exists, the State Machine shall monitor these conditions. When any condition is met, the corresponding event shall be generated and processed.

Condition	Event
The Pull BLOB State Machine is instantiated in the Initial state.	Block Reception Start
A BLOB Partial Block Report message is sent.	Partial Block Report Sent
A valid BLOB Chunk Transfer message is received that contains a new chunk (a chunk that was not already received).	New Chunk Received
A BLOB Chunk Transfer message is received, and the chunk has already been received.	Chunk Received
The New Chunk timer expires.	New Chunk Timer Expired
The Reception timer expires.	Reception Timer Expired
The Block Complete timer expires.	Block Complete Timer Expired
All chunks requested by the BLOB Partial Block Report message or BLOB Block Status message were received.	All Requested Chunks Received
In the Check Chunks state, not all chunks of the active block have been received.	Block Not Complete
In the Check Chunks state, all chunks of the active block have been received.	Block Complete
In the Check The Receive BLOB Timeout Timer state, the Receive BLOB Timeout timer is not running.	Timer Expired
In the Check The Receive BLOB Timeout Timer state, the Receive BLOB Timeout timer is running.	Timer Active
In the Check The Receive BLOB Timeout Timer After All Chunks Are Received state, the Receive BLOB Timeout timer is not running.	Timer Expired
In the Check Receive BLOB Timeout Timer After All Chunks Are Received state, the Receive BLOB Timeout timer is running.	Timer Active
The server determines that the client has finished the transfer.	Transfer Complete

Table 5.6. Pull BLOB State Machine events

While the Pull BLOB State Machine state is in the Waiting For First Chunk state or in the Chunks Reception state, the reception of a BLOB Chunk Transfer message does not generate an event if the chunk identified by the chunk number has already been received. However, while the Pull BLOB State Machine is in the All Chunks Received state, a chunk that has already been received does generate an event.

While the Pull BLOB State Machine is in the All Chunks Received state, the Pull BLOB State Machine continues to send the BLOB Partial Block Report messages until one of the following happens:

The Receive BLOB Timeout timer expires.
If the current block is not the last block, then the client starts a new block, in which case a new Pull BLOB State Machine is instantiated.
If the current block is the last block, then the server determines that the client knows the transfer is complete. For example, a higher-layer model may indicate that the client considers the transfer complete.

If the Receive BLOB Timeout timer expires, and the current block is the last block, then the server remains in the Complete phase. If the Receive BLOB Timeout timer expires, and the current block is not the last block, then the server enters the Suspended phase.

Table 5.7 defines the state transitions of the Pull BLOB State Machine and the resulting actions that the BLOB Transfer Server shall execute. Event actions shall be processed during a state transition (i.e., after leaving the current state but before entering a new state).

State	Event	Event Actions	New State
Send Partial Block Report	Partial Block Report Sent	Start the New Chunk timer from the initial value	Waiting For First Chunk
Initial	Block Reception Start	Stop any previously started New Chunk timer, Reception timer, and Block Complete timer AND Start the New Chunk timer from the initial value	Waiting For First Chunk
Waiting For First Chunk	New Chunk Received	Stop the New Chunk timer AND Start the Reception timer from the initial value	Chunks Reception
Waiting For First Chunk	New Chunk Timer Expired	–	Check The Receive BLOB Timeout Timer
Check The Receive BLOB Timeout Timer	Timer Active	Prepare and send a BLOB Partial Block Report message	Send Partial Block Report
Check The Receive BLOB Timeout Timer	Timer Expired	–	Block Reception Failed
Chunks Reception	Reception Timer Expired	Prepare and send a BLOB Partial Block Report message	Send Partial Block Report
Chunks Reception	All Requested Chunks Received	Stop the Reception timer	Check Chunks
Check Chunks	Block Not Complete	Prepare and send a BLOB Partial Block Report message	Send Partial Block Report
Check Chunks	Block Complete	Start the Block Complete timer from the initial value AND Prepare and send a BLOB Partial Block Report message	All Chunks Received
All Chunks Received	Chunk Received	Prepare and send a BLOB Partial Block Report message	All Chunks Received
All Chunks Received	Block Complete Timer Expired	–	Check The Receive BLOB Timeout Timer After All Chunks Are Received
Check The Receive BLOB Timeout Timer After All Chunks Are Received	Timer Active	Start the Block Complete timer from the initial value AND Prepare and send a BLOB Partial Block Report message	All Chunks Received
Check The Receive BLOB Timeout Timer After All Chunks Are Received	Timer Expired	–	Stopped
All Chunks Received	Transfer Complete	Stop the Block Complete timer	Stopped

Table 5.7. Pull BLOB State Machine transitions and actions

5.2.5. Push BLOB procedure

When the Push BLOB Transfer mode is used, the Push BLOB procedure is used to retrieve the chunks.

The Push BLOB procedure starts when the BLOB Transfer Server receives a BLOB Block Start message for a new block. The procedure completes when the BLOB Transfer Server receives and processes the BLOB Chunk Transfer message and the Missing Chunks state indicates that no chunks are missing.

This procedure does not have a separate behavior other than behaviors described in Section 5.3, excluding the behaviors specified when the Transfer Mode state is set to Pull BLOB Transfer mode.

5.3. Behavior

This section describes behaviors for states and messages for the BLOB Transfer Server model.

When a BLOB Transfer Server model receives any BLOB Transfer messages, and the Receive BLOB Timeout timer is running, then the Server shall start the timer from the initial value, in seconds, calculated from the following formula:

Equation 0.

Receive BLOB Timeout =10×(Server Timeout Base state+1) [seconds]

When the BLOB Transfer Server checks error conditions while processing a received message, the server shall check the error conditions one by one starting with the first item. This applies to the error handling behavior in Section 5.3.1 through Section 5.3.11.

When the BLOB Transfer Server originates a message, the server shall set the TTL field of the Network PDU to the value indicated by the Transfer TTL state.

During a BLOB transfer, a BLOB Transfer server will transition through several phases. The phase state values and the procedures and events that cause phase state transitions are shown in Figure 5.2.

Figure 5.2. BLOB transfer phase transitions

5.3.1. Receiving a BLOB Transfer Get message

When a BLOB Transfer Server receives a BLOB Transfer Get message, the BLOB Transfer Server shall respond with a BLOB Transfer Status message with the Status field set to Success.

Error handling. When a BLOB Transfer Server receives a BLOB Transfer Get message, and the message is not processed successfully because an implementation-specific error (e.g., a memory allocation error or flash memory error) has occurred, then the BLOB Transfer Server shall respond with a BLOB Transfer Status message with the Status field set to Internal Error.

5.3.2. Receiving a BLOB Transfer Start message

Transfer starting. When a BLOB Transfer Server receives a BLOB Transfer Start message, and the Transfer Phase state is Waiting For Transfer Start, and the value of the BLOB ID field matches the value of the Expected BLOB ID state, then the server shall compute the values defined by the following equations.

For the purposes of these equations, the variables identified in Table 5.8 shall be set to the value provided by the source indicated in the table and the values of the remaining variables shall then be derived in accordance with the formulas.

Variable Name	Source of Value for Variable	Reference
Max Block Size Log	Max Block Size Log state	Section 3.2.7.2
Max Total Chunks	Max Total Chunks state	Section 3.2.7.3
Max Chunk Size	Max Chunk Size state	Section 3.2.7.4
Max BLOB Size	Max BLOB Size state	Section 3.2.7.5
Server MTU Size	Server MTU Size state	Section 3.2.7.6
Client MTU Size	BLOB Transfer Start message, Client MTU Size field	Section 4.2
BLOB size	BLOB Transfer Start message, BLOB size field	Section 4.2
Block Size Log	BLOB Transfer Start message, Block Size Log field	Section 4.2

Table 5.8. Sources of values for variables

Equation 0.

Transfer MTU Size=min f () (C i e n t M T U S i z e, S e r v e r M T U S i z e)

Equation 0.

Total Blocks=ceil (\frac{BLOB size}{2^{B l o c k S i z e L o g}})

Equation 0.

Transfer Max Chunk Size=min(Transfer MTU Size-3, Max Chunk Size)

Equation 0.

Transfer Max Total Chunks=min(8×(Transfer MTU Size-6), Max Total Chunks)

Equation 0.

Transfer Max Total Blocks=8×(Transfer MTU Size-19)

Equation 0.

Transfer Max Block Size Log= {min(floor(Log}_{2} (T r a n s f e r M a x T o t a l C h u n k s \times T r a n s f e r M a x C h u n k S i z e)), M a x B l o c k S i z e L o g)

Equation 0.

Transfer Max BLOB Size= {min(Transfer Max Total Blocks×2}^{T r a n s f e r M a x B l o c k S i z e L o g}, M a x B L O B S i z e)

Then, the BLOB Transfer Server shall check whether the message is successfully processed (i.e., it does not result in any error conditions listed in Table 5.9).

If the message is successfully processed, then the BLOB Transfer Server shall perform the following steps:

The server shall set the following states:
- The Transfer Phase state shall be set to Waiting For Next Block.
- The BLOB Size state, the Block Size Log state, the Client MTU Size state, and the Transfer Mode state shall be set to the values of the corresponding fields from the BLOB Transfer Start message.
- The Blocks Not Received state shall be set to indicate that no block has been received.
The server shall start the Receive BLOB Timeout timer from the initial value set to the Server Timeout value calculated using the equation in Section 5.3.
The server shall respond with a BLOB Transfer Status message with the Status field set to Success (see Section 5.3.4).

If the message is not successfully processed (i.e., it results in an error condition listed in Table 5.9), then the BLOB Transfer Server shall respond with a BLOB Transfer Status message with the Status field set to the corresponding status code defined in Table 5.9.

Error Condition	Status Code Name (see Table 3.17)
The selected transfer mode is not supported (i.e., Transfer Mode field value indicates a transfer mode whose corresponding bit in the Supported Transfer Mode state is equal to 0)	Unsupported Transfer Mode
BLOB Size field value is greater than the Transfer Max BLOB Size value	BLOB Too Large
Block Size Log field value is less than the Min Block Size Log state	Invalid Block Size
Block Size Log field value is greater than the Transfer Max Block Size Log value	Invalid Block Size
Total Blocks value is greater than the Transfer Max Total Blocks value	Invalid Parameter

Table 5.9. Error conditions for the BLOB Transfer Start message

Error handling. When a BLOB Transfer Server receives a BLOB Transfer Start message, and the Transfer Phase state is Inactive, then the BLOB Transfer Server shall respond with a BLOB Transfer Status message with the Status field set to Wrong Phase.

When a BLOB Transfer Server receives a BLOB Transfer Start message, and the Transfer Phase state is not Inactive, and the value of the BLOB ID field is not equal to the Expected BLOB ID state, then the server shall respond with a BLOB Transfer Status message with the Status field set to Wrong BLOB ID.

When a BLOB Transfer Server receives a BLOB Transfer Start message, and the message is not processed successfully because an implementation-specific error (e.g., a memory allocation error or flash memory error) has occurred, then the BLOB Transfer Server shall respond with a BLOB Transfer Status message with the Status field set to Internal Error.

Idempotency. When a BLOB Transfer Server receives a BLOB Transfer Start message, and the Transfer Phase state is not Waiting For Transfer Start and is not Inactive and is not Suspended, and the value of the BLOB ID field is equal to the Expected BLOB ID state, and all conditions in Table 5.10 are met, then the server shall respond with a BLOB Transfer Status message with the Status field set to Success.

When a BLOB Transfer Server receives a BLOB Transfer Start message, and the Transfer Phase state is not Waiting For Transfer Start and is not Inactive, and the value of the BLOB ID field is equal to the Expected BLOB ID state, and at least one of the conditions in Table 5.10 is not met, then the server shall respond with a BLOB Transfer Status message with the Status field set to Wrong Phase.

Table 5.10 defines conditions used in idempotency checks when a BLOB Transfer Start message is received.

Condition
Transfer Mode field is equal to Transfer Mode state
BLOB Size field is equal to BLOB Size state
Block Size Log field is equal to Block Size Log state
Client MTU Size field is equal to Client MTU Size state

Table 5.10. Conditions used in idempotency checks when a BLOB Transfer Start message is received

Resuming. When a BLOB Transfer Server receives a BLOB Transfer Start message, and the Transfer Phase state is Suspended, and the value of the BLOB ID field is equal to the Expected BLOB ID state, and all conditions in Table 5.10 are met, then the server shall set the Transfer Phase state to Waiting For Next Block, shall start the Receive BLOB Timeout timer from the initial value calculated using the equation in Section 5.3, and shall respond with a BLOB Transfer Status message with the Status field set to Success.

5.3.3. Receiving a BLOB Transfer Cancel message

Canceling a transfer. When a BLOB Transfer Server receives a BLOB Transfer Cancel message, and the Transfer Phase state is not Inactive, and the Expected BLOB ID state is equal to the value of the BLOB ID field, then the server shall cancel the Initialize And Receive BLOB procedure, and shall respond with a BLOB Transfer Status message with the Status field set to Success.

Error handling. When a BLOB Transfer Server receives a BLOB Transfer Cancel message, and the Transfer Phase state is not Inactive, and the Expected BLOB ID state is not equal to the value of the BLOB ID field, then the server shall respond with a BLOB Transfer Status message with the Status field set to Wrong BLOB ID.

When a BLOB Transfer Server receives a BLOB Transfer Cancel message, and the message is not processed successfully because an implementation-specific error (e.g., a memory allocation error or flash memory error) has occurred, then the BLOB Transfer Server shall respond with a BLOB Transfer Status message with the Status field set to Internal Error.

Idempotency. When a BLOB Transfer Server receives a BLOB Transfer Cancel message, and the Transfer Phase state is Inactive, then the server shall respond with a BLOB Transfer Status message with the Status field set to Success.

5.3.4. Sending a BLOB Transfer Status message

A BLOB Transfer Server sends a BLOB Transfer Status message as a response to a BLOB Transfer Get message, a BLOB Transfer Start message, or a BLOB Transfer Cancel message.

The server shall set the Transfer Phase field of the message to the value of the Transfer Phase state and shall set the Transfer Mode field to the value of the Transfer Mode state.

When the Transfer Phase state is Inactive, the server shall omit the BLOB ID, BLOB Size, Block Size Log, Transfer MTU Size, and Blocks Not Received fields.

When the Transfer Phase state is Waiting For Transfer Start, the server shall set the BLOB ID field to the value of the Expected BLOB ID state and shall omit the BLOB Size, Block Size Log, Transfer MTU Size, and Blocks Not Received fields.

When the Transfer Phase state is not Waiting For Transfer Start and is not Inactive, the server shall set the BLOB ID field to the value of the Expected BLOB ID state, and shall set the BLOB Size, Block Size Log, and Blocks Not Received fields of the BLOB Transfer Status message to the values of the corresponding states, and shall set the Transfer MTU Size field to the calculated Transfer MTU Size value described in Section 5.3.2.

5.3.5. Receiving a BLOB Block Get message

Get block information. When a BLOB Transfer Server receives a BLOB Block Get message, and the Transfer Phase state is Waiting For Next Block, or Waiting For Next Chunk, or Complete, then the server shall respond with a BLOB Block Status message with the Status field set to Success.

Information unavailable. When a BLOB Transfer Server receives a BLOB Block Get message, and the Transfer Phase state is Suspended, then the server shall respond with a BLOB Block Status message with the Status field set to Information Unavailable.

Wrong phase. When a BLOB Transfer Server receives a BLOB Block Get message, and the Transfer Phase state is Inactive or Waiting For Transfer Start, then the server shall respond with a BLOB Block Status message with the Status field set to Wrong Phase.

Error handling. When a BLOB Transfer Server receives a BLOB Block Get message, and the message is not processed successfully because an implementation-specific error (e.g., a memory allocation error or flash memory error) has occurred, then the BLOB Transfer Server shall respond with a BLOB Block Status message with the Status field set to Internal Error.

5.3.6. Receiving a BLOB Block Start message

When a BLOB Transfer Server receives a BLOB Block Start message, the server shall calculate the Incoming Block Size value in the following way:

For all blocks except the last, the server uses the following formula:

Equation 0.

{Incoming Block Size=2}^{B l o c k S i z e L o g}

For the last block, the server calculates the following value:

Equation 0.

{modulo(BLOB size, 2}^{B l o c k S i z e L o g})

If the calculated value is 0, then the Incoming Block Size value is $2^{B l o c k S i z e L o g}$ . Otherwise, the Incoming Block Size value is the calculated value.

Same block. When a BLOB Transfer Server receives a BLOB Block Start message, and the Transfer Phase state is Waiting For Next Chunk, then the server shall compare the value of the Chunk Size field to the value of the Chunk Size state, and shall compare the value of the Block Number field to the value of the Block Number state. If both comparisons show that the values are equal, then the server shall respond with a BLOB Block Status message with the Status field set to Success. If at least one of the comparisons shows that the values are unequal, then the server shall respond with a BLOB Block Status message with the Status field set to Wrong Phase.

New block. When a BLOB Transfer Server receives a BLOB Block Start message, and the Transfer Phase state either is Waiting For Next Block or is Suspended, and the block identified by the Block Number field has not been received, and the message is successfully processed (i.e., it does not result in any error condition in Table 5.11), then the server shall perform the following steps:

The server shall set the following states:
- The server shall set the Transfer Phase state to Waiting For Next Chunk.
- The server shall set the Chunk Size state and the Block Number state to the values of the corresponding fields from the BLOB Block Start message.
- The server shall clear the BLOB Block Data state, and shall set the Missing Chunks state to indicate that no chunk has been received.
- The server shall set the Current Block Size state to the Incoming Block Size value.
The server shall respond with a BLOB Block Status message with the Status field set to Success.
When the Transfer Mode state is set to Pull BLOB Transfer mode, the server shall stop the ongoing Pull BLOB procedure, if any, and shall start a new Pull BLOB procedure by instantiating a Pull BLOB State Machine in the Initial state. When the Transfer Mode state is set to Push BLOB Transfer mode, the server shall stop the ongoing Push BLOB procedure, if any, and shall start the new Push BLOB procedure.

Block already received. When a BLOB Transfer Server receives a BLOB Block Start message, and the Transfer Phase state either is Waiting For Next Block or is Suspended, and the Blocks Not Received state indicates that the block identified by the Block Number field has been received, and the message is successfully processed (i.e., it does not result in any error condition in Table 5.11), then the server shall set the Block Number state to the value of the Block Number field, shall set the Chunk Size state to the value of the Chunk Size field, and shall respond with a BLOB Block Status message with the Status field set to Success.

Error handling. When a BLOB Transfer Server receives a BLOB Block Start message, and the Transfer Phase state is either Waiting For Next Block or is Suspended, and the message is not successfully processed (i.e., it results in an error condition listed in Table 5.11), then the server shall respond with a BLOB Block Status message with the Status field set to the corresponding status code defined in Table 5.11.

In all cases, the remaining fields of the BLOB Block Status message shall be populated as defined in Section 4.7 (BLOB Block Status).

Error Condition	Status Code Name (see Table 3.17)
Block Number field value is equal to or greater than the Transfer Max Total Blocks value (see Section 5.3.2)	Invalid Block Number
Chunk Size field value is greater than the Transfer Max Chunk Size value (see Section 5.3.2)	Invalid Chunk Size
Value $c e i l (\frac{Incoming Block Size value}{Chunk Size field})$ is greater than the Transfer Max Total Chunks value (see Section 5.3.2)	Invalid Chunk Size

Table 5.11. Error conditions for the BLOB Block Start message

When a BLOB Transfer Server receives a BLOB Block Start message, and the Transfer Phase state is Waiting For Transfer Start or is Inactive, then the server shall respond with a BLOB Block Status message with the Status field set to Wrong Phase.

When a BLOB Transfer Server receives a BLOB Block Start message, and the message is not processed successfully because an implementation-specific error (e.g., a memory allocation error or flash memory error) has occurred, then the BLOB Transfer Server shall respond with a BLOB Block Status message with the Status field set to Internal Error.

Transfer complete. When a BLOB Transfer Server receives a BLOB Block Start message, and the Transfer Phase state is Complete, and the message is successfully processed (i.e., it does not result in any error condition in Table 5.11), then the server shall respond with a BLOB Block Status message with the Status field set to Success.

When a BLOB Transfer Server receives a BLOB Block Start message, and the Transfer Phase state is Complete, and the message is not successfully processed (i.e., it results in an error condition listed in Table 5.11), then the server shall respond with a BLOB Block Status message with the Status field set to the corresponding status code defined in Table 5.11.

5.3.7. Sending a BLOB Partial Block Report message

When the Transfer Mode state of a BLOB Transfer Server is Pull BLOB Transfer mode, and the server is ready to receive new chunks, then the server sends a BLOB Partial Block Report message to the BLOB Transfer Client.

When the BLOB Transfer Server sends a BLOB Partial Block Report message, the server shall start the Select Missing Chunks procedure (see Section 5.2.3) and shall process the Requested Chunks List output as follows:

If the Requested Chunks List output is not empty, then the Encoded Missing Chunks field shall be set to the Requested Chunks List output.
If the Requested Chunks List output is empty, then the Encoded Missing Chunks field shall be omitted.

5.3.8. Sending a BLOB Block Status message

A BLOB Transfer Server sends a BLOB Block Status message in response to a BLOB Block Start message or a BLOB Block Get message.

When the BLOB Transfer Server sends a BLOB Block Status message, it shall set the Block Number field and the Chunk Size field to the value of the corresponding states.

If the Transfer Mode state is No Active Transfer, then the BLOB Transfer Server shall set the Format field to All Chunks Missing.

Push transfer mode. If the Transfer Mode state is Push BLOB Transfer mode, and the Blocks Not Received state indicates that the block has not been received, then the BLOB Transfer Server shall perform one of the following actions:

If the Missing Chunks state indicates that all chunks are missing (i.e., the Missing Chunks state indicates that no chunk has been received), then the server shall set the Format field to All Chunks Missing and shall omit the Missing Chunks field.
If the Missing Chunks state indicates that at least one, but not all, of the chunks is missing, then the server shall set the fields of the BLOB Block Status message as follows:
- The Format field shall be set to Some Chunks Missing (see Table 4.8).
- The Missing Chunks field shall be set to indicate the missing chunks (as described in Section 4.7).
- The Encoded Missing Chunks field shall be omitted.

If the Transfer Mode state is Push BLOB Transfer mode, and the Blocks Not Received state indicates that the block has already been received, then the server shall set the Format field to No Missing Chunks and shall omit the Missing Chunks field.

Pull transfer mode. If the Transfer Mode state is Pull BLOB Transfer mode, and the Blocks Not Received state indicates that the block has not been received, then the BLOB Transfer Server shall perform the following actions:

The server shall start the Select Missing Chunks procedure (see Section 5.2.3).
The server shall set the following fields:
- The Format field shall be set to Encoded Missing Chunks (see Table 4.8).
- The Missing Chunks field shall be omitted.
- The Encoded Missing Chunks field shall be set to the Requested Chunks List output of the Select Missing Chunks procedure if the Requested Chunks List output is not empty. If the Requested Chunks List output is empty, the Encoded Missing Chunks field shall be omitted.

If the Transfer Mode state is Pull BLOB Transfer mode, and the Blocks Not Received state indicates that the block has already been received, then the server shall set the Format field to Encoded Missing Chunks and shall omit the Encoded Missing Chunks field.

5.3.9. Receiving a BLOB Chunk Transfer message

When a BLOB Transfer Server receives a BLOB Chunk Transfer message, and all conditions listed in Table 5.12 are met, then the server shall process the message as follows:

Chunk already received. If the chunk identified by the Chunk Number field has already been received for the active block, then the BLOB Transfer Server shall perform one of the following actions:

If the Transfer Mode state is Pull BLOB Transfer mode, then the server shall perform one of the following actions:
- If the Pull BLOB State Machine is in the All Chunks Received state, then the BLOB Transfer Server shall generate a Chunk Received event and shall then stop processing the BLOB Chunk Transfer message.
- If the Pull BLOB State Machine is in a state other than the All Chunks Received state, then the server shall stop processing the BLOB Chunk Transfer message.
If the Transfer Mode state is Push BLOB Transfer mode, then the server shall stop processing the BLOB Chunk Transfer message.

New chunk. If the chunk identified by the Chunk Number field has not yet been received for the active block, then the BLOB Transfer Server shall perform the following actions:

It shall store the received chunk data in the BLOB Block Data state and shall set the Missing Chunks state to indicate that the chunk identified by the Chunk Number field in the message has been received.
If the Transfer Mode state is Pull BLOB Transfer mode, then the server shall perform one of the following actions:
- If the Pull BLOB State Machine is in the Waiting For First Chunk state, then the BLOB Transfer Server shall generate a New Chunk Received event.
- If the Pull BLOB State Machine is in the Chunks Reception state, and the BLOB Transfer Server has received all of the chunks requested in the most recent BLOB Partial Block Report message that it sent, then the server shall generate an All Requested Chunks Received event.

Block complete. If the Missing Chunks state indicates that no chunks are missing, then the BLOB Transfer Server shall perform the following steps.

The BLOB Transfer Server shall set the following states:
- The Blocks Not Received state shall be set to indicate that the block identified by the Block Number state has been received.
- The BLOB Block Data state shall be stored in the BLOB Data state.
Depending on the value of the Blocks Not Received state, the server shall do one of the following:
- If the Blocks Not Received state indicates that at least one block is missing, then the server shall set the Transfer Phase state to Waiting For Next Block.
- If the Blocks Not Received state indicates that no blocks are missing, then the server shall set the Transfer Phase state to Complete and shall stop the Receive BLOB Timeout timer.
If the Transfer Mode state is Pull BLOB Transfer mode, then the server shall generate a Block Complete event.

Error handling. When a BLOB Transfer Server receives a BLOB Chunk Transfer message, and at least one condition listed in Table 5.12 is not met, then the server shall ignore the message.

Message Processing Condition
The Transfer Phase state is Waiting For Next Chunk
The value of the Chunk Number field is less than or equal to the Total Chunks state
The received chunk is not the last chunk in the current block, and the size of the Chunk Data field is equal to the Chunk Size state
The received chunk is the last chunk in the current block, the value of the Chunk Size state is not a divisor of the Current Block Size state, and the size of the Chunk Data field is $modulo(Current Block Size, Chunk Size)$
The received chunk is the last chunk in the current block, the value of the Chunk Size state is a divisor of the Current Block Size state, and the size of the Chunk Data field is equal to the Chunk Size state

Table 5.12. Error conditions for the BLOB Chunk Transfer message

5.3.10. Receiving a BLOB Information Get message

When a BLOB Transfer Server receives a BLOB Information Get message, then the server shall respond with a BLOB Information Status message (see Section 4.11).

5.3.11. Sending a BLOB Information Status message

A BLOB Transfer Server sends a BLOB Information Status message in response to a BLOB Information Get message.

When a BLOB Transfer Server sends a BLOB Information Status message, then the server shall set the Min Block Size Log field, the Max Block Size Log field, the Max Total Chunks field, the Max Chunk Size field, the Max BLOB Size field, and the Server MTU Size field to the values of the corresponding states.

6. BLOB Transfer Client model

6.1. Description

The BLOB Transfer Client model is used by a higher-layer application to transfer a BLOB to one or more BLOB Transfer Servers. The higher-layer application provides the inputs to the procedures executed by the client (e.g., it provides the BLOB to be transferred, the unicast addresses for the servers, and the Transfer TTL).

The BLOB Transfer Client is a root model (i.e., it does not extend any other models).

The access layer security on the BLOB Transfer Client model uses application keys.

The BLOB Transfer Client model defines the messages listed in Table 6.1, and requires one element: the BLOB Transfer Client Main element. The BLOB Transfer Client Main element contains the BLOB Transfer Client main model.

Table 6.1 lists the BLOB Transfer Client model messages. The model shall support receiving the messages marked as mandatory in the Rx column and shall support sending the messages marked as mandatory in the Tx column.

Element	Model Name	Procedure / Sub-procedure	Message	Rx	Tx
BLOB Transfer Client Main	BLOB Transfer Client	Determine Transfer Status	BLOB Transfer Get	–	M
		Transfer BLOB	BLOB Transfer Start	–	M
		Cancel Transfer	BLOB Transfer Cancel	–	M
		Determine Transfer Status, Cancel Transfer, Transfer BLOB	BLOB Transfer Status	M	–
		Determine Block Status	BLOB Block Get	–	M
		Send Block	BLOB Block Start	–	M
		Send Block	BLOB Partial Block Report	M	–
		Send Block, Determine Block Status	BLOB Block Status	M	–
		Send Data	BLOB Chunk Transfer	–	M
		Retrieve Capabilities	BLOB Information Get	–	M
		Retrieve Capabilities	BLOB Information Status	M	–

Table 6.1. BLOB Transfer Client elements, procedures, and messages

6.2. Behavior

This section describes behaviors of procedures and messages for the BLOB Transfer Client model.

When a BLOB Transfer Client executes a procedure that sets the Transfer TTL state, then, when originating a message during that procedure, the client shall set the TTL field of the Network PDU to the value indicated by the Transfer TTL state. If the procedure does not set the Transfer TTL state, then the client shall set the TTL field of the Network PDU to the value indicated by the Transfer TTL input.

When a BLOB Transfer Client executes a procedure that sets the AppKey Index state, then, when originating a message during that procedure, the client shall use the key indicated by the AppKey Index state to encrypt the message. If the procedure does not set the AppKey Index state, then the client shall use the key indicated by the AppKey Index input to encrypt the message.

When a BLOB Transfer Client executes a procedure that sets the BLOB Multicast Address state, then, when originating a message during that procedure, the client shall use the multicast address indicated by the BLOB Multicast Address state. Otherwise, the client shall use the multicast address input as the multicast address:

If the multicast address is the Unassigned address, then the message shall be sent to each unicast address in the Address List input.
If the multicast address is not the Unassigned address, then the message should be sent to the address indicated by the multicast address input.

The client could use a mix of multicast and unicast addressing. For example, the client can set rules to determine when to use unicast addressing or multicast addressing based on the number of intended recipients.

6.2.1. Calculate Client Timeout procedure

The Calculate Client Timeout procedure is executed on a BLOB Transfer Client to calculate the Client Timeout value.

The client calculates a Client Timeout value, in milliseconds, from the following formula:

Equation 0.

Client Timeout=(10,000×(Client Timeout Base+2))+(100×Transfer TTL)[milliseconds]

6.2.2. Retrieve Capabilities procedure

The Retrieve Capabilities procedure is executed on a BLOB Transfer Client to retrieve transfer capabilities of BLOB Transfer Servers.

As inputs, the Retrieve Capabilities procedure takes a multicast address, an AppKey Index, a Transfer TTL, and a list of unicast addresses identifying BLOB Transfer Servers (i.e., the Address List).

The Retrieve Capabilities procedure consists of the following steps:

The BLOB Transfer Client shall remove all entries from the BLOB Receivers Capabilities state.
The BLOB Transfer Client shall send a BLOB Information Get message to each BLOB Transfer Server in the Address List input and shall wait for the response.
The client shall start a Client Timeout timer from the initial value set to the output value of the Calculate Client Timeout procedure (see Section 6.2.1).

While the timer is running, the client may repeat the request to the BLOB Transfer Servers that have not responded. The number of request repetitions is implementation specific.
The BLOB Transfer Client shall store the Capabilities state values (see Section 3.2.7) from each received BLOB Information Status message in the BLOB Receivers Capabilities state.

6.2.2.1. Sending a BLOB Information Get message

To query the Capabilities state of a BLOB Transfer Server, a BLOB Transfer Client shall send a BLOB Information Get message. The response to the BLOB Information Get message is a BLOB Information Status message (see Section 4.11).

6.2.2.2. Receiving a BLOB Information Status message

When the BLOB Transfer Client model receives a BLOB Information Status message, it stores the value of the Capabilities state of the BLOB Transfer Server in the BLOB Receivers Capabilities state.

6.2.3. Transfer BLOB procedure

The Transfer BLOB procedure is executed on a BLOB Transfer Client to initiate and control the BLOB transfer to one or more BLOB Transfer Servers.

As inputs, the Transfer BLOB procedure takes a list of unicast addresses identifying BLOB Transfer Servers (i.e., the Address List), a Multicast Address, an AppKey Index, a Transfer TTL, a BLOB ID, BLOB Data, a Transfer Mode, and a Client Timeout Base.

The Transfer BLOB procedure has three phases: Initializing, Active and Suspended. When the procedure is running step 1, 2, 3, 4 or 5, the phase is set to Initializing, and the procedure cannot be suspended. When the procedure is in step 6, the phase is Active and the procedure may be suspended. When the procedure is in the Suspended phase it may be resumed and the phase set to Active.

The Transfer BLOB procedure consists of the following steps:

The BLOB Transfer Client shall remove all entries from the BLOB Receivers state and then shall add an entry for each entry in the Address List input, and shall initialize each entry in the BLOB Receivers state as follows:
- The Address field shall be set to the value of the entry in the Address List input.
- The Retrieved Transfer Phase field shall be set to Unknown.
- The Status field shall be set to Success.
- The Blocks Not Received field shall be set to indicate that no block has been received.
- The Missing Chunks field shall be set to indicate that no chunk has been received.
The procedure shall set the phase to Initializing.
The BLOB Transfer Client shall then add all receivers from the BLOB Receivers state to the Active BLOB Receivers state, shall set the BLOB Size state to the size of the BLOB input, and shall set the BLOB Multicast Address state, the AppKey Index state, the Transfer TTL state, the BLOB ID state, the BLOB Data state, the Transfer Mode state, and the Client Timeout Base state to the values of the corresponding inputs.
The BLOB Transfer Client shall divide the BLOB into blocks and shall divide each block into chunks. The client determines the size of a block and the size of a chunk. The client should use the values retrieved from the Retrieve Capabilities procedure, which are stored in the BLOB Receivers Capabilities state, to determine a suitable block size, chunk size (which depends on the number of chunks in a block), and MTU size for all receivers.

After the size of a block and of a chunk have been determined, the client shall set the Block Size Log state and the Chunk Size state to those values as described in Section 6.2.4.

The BLOB Transfer Client should set a value of the Block Size Log state that maximizes the number of receivers that can participate in the transfer:
- The value should be at least as large as the largest Min Block Size Log value in the BLOB Receivers Capabilities state.
- The value should be no larger than the smallest Max Block Size Log value in the BLOB Receivers Capabilities state.
If these constraints cannot be met for all receivers, then the BLOB Transfer Client should choose a value of the Block Size Log state that can be accepted by as many receivers as possible.
The BLOB Transfer Client shall send the BLOB Transfer Start message with the Transfer Mode field, the Block Size Log field, the BLOB ID field, and the BLOB Size field set to the values of the corresponding states, with the Client MTU field set to the computed value, and with the Timeout field set to the value of the Client Timeout Base state.
The client shall start a Client Timeout timer from the initial value set to the output value of the Calculate Client Timeout procedure (see Section 6.2.1).

While the timer is running, the client may repeat the request to the receivers that have not responded with a BLOB Transfer Status message. The number of request repetitions is implementation specific. When the timer expires, the client shall update the Active BLOB Receivers state by removing the receivers that have not responded or that have responded with a BLOB Transfer Status message with the Status field not equal to Success.
The BLOB Transfer Client shall start sending blocks and shall set the phase to Active. The missing blocks (identified by the Blocks Not Received field in the BLOB Receivers state) can be sent in any order. The client may select any block to send that has not yet been received by one or more receivers.

To send a block, the client shall set the Block Number state to the block number of the selected block, shall start the Send Block sub-procedure, and shall wait for the procedure to complete. The client shall repeat these steps until all blocks are sent to all receivers on the Active BLOB Receivers List.

Suspend. The Transfer BLOB procedure may be set to the Suspended phase when the phase is Active; otherwise the Transfer BLOB procedure cannot be suspended. When the Transfer BLOB procedure is being suspended, it shall stop running step 6 of the procedure, and set the procedure phase to Suspended.

When the Send Block sub-procedure completes with a timeout result, the Transfer BLOB procedure shall be suspended.

Resume. The Transfer BLOB procedure may be resumed when the Transfer BLOB procedure is in the Suspended phase. When the Transfer BLOB procedure is resumed, the BLOB Transfer Client shall set the phase to Active and shall restart step 4 of the procedure. The BLOB Transfer Client should add all receivers from the BLOB Receivers state that are timed-out to the Active BLOB Receivers state. If the BLOB Transfer Client determines that some of the receivers are not responding, then such receivers are skipped from being added to the Active BLOB Receivers state.

Cancel. The Transfer BLOB procedure can be canceled at any time by a higher-layer model or application.

The Transfer BLOB procedure completes when any of the following conditions is met:

If a Send Block sub-procedure fails, then the Transfer BLOB procedure fails.
If the Active BLOB Receivers state is empty, then the Transfer BLOB procedure fails.
If the Transfer Phase state is set to Complete for all remaining receivers in the Active BLOB Receivers state (i.e., the BLOB transfer completed successfully on at least one receiver), then the Transfer BLOB procedure completes successfully.

6.2.3.1. Sending a BLOB Transfer Start message

To initiate the BLOB transfer, the BLOB Transfer Client shall send a BLOB Transfer Start message. The response to the BLOB Transfer Start message is a BLOB Transfer Status message (see Section 4.4).

6.2.4. Send Block sub-procedure

The Send Block sub-procedure procedure is executed on a BLOB Transfer Client to send one block to one or more BLOB Transfer Servers.

Before sending the block, the client may set the Chunk Size state based on the current radio environment. A smaller chunk size could increase the probability of successful delivery of each chunk when the radio environment is poor, increasing the speed of the block transfer.

The Send Block sub-procedure consists of the following steps:

The BLOB Transfer Client shall select the value of the Chunk Size state.

The client should set a value of the Chunk Size state that maximizes the number of receivers that can participate in the transfer:
- The value should not exceed the smallest Max Chunk Size value in the BLOB Receivers Capabilities state.
- The value should be chosen so that the computed value of Max Chunks for the block (see Section 5.3.2) does not exceed the smallest Max Chunks in the BLOB Receivers Capabilities state.
The value of the Chunk Size state shall be a value that can be accepted by at least one receiver. The Chunk Size state should be a value that can be accepted by as many receivers as possible.
The BLOB Transfer Client shall send a BLOB Block Start message to each receiver in the Active BLOB Receivers state. The Block Number field shall be set to the value of the Block Number state, and the Chunk Size field shall be set to the value of the Chunk Size state.
The client shall start a Client Timeout timer from the initial value set to the output value of the Calculate Client Timeout procedure (see Section 6.2.1).

While the timer is running, the client may repeat the request to the receivers that have not responded with a BLOB Block Status message. The number of request repetitions is implementation specific.

The client shall update the Active BLOB Receivers state by removing the receivers that have responded with a BLOB Block Status message with the Status field not equal to Success. The Missing Chunks value for the corresponding entry in the BLOB Receivers state shall be set to Unknown.

When all receivers have responded with a BLOB Block Status message and the Active BLOB Receivers state is not empty, then the procedure shall advance to step 4.

When all receivers have responded with a BLOB Block Status message and the Active BLOB Receivers state is empty, then the procedure fails.

When the timer expires and at least one receiver has responded with the Status field equal to Success, then the procedure shall advance to step 4.

When the timer expires and none of the receivers have responded with the Status field equal to Success, then the procedure shall complete with a timeout result.
The client shall stop the timer started in Step 3.
The client shall send the chunks of the block to the receivers using the mechanism determined by whether the Push BLOB Transfer mode or the Pull BLOB Transfer mode is used.

Push BLOB Transfer mode
1. The client shall start the Send Data sub-procedure and wait for it to complete.
2. The client shall execute the Determine Block Status sub-procedure and wait for it to complete. When the Determine Block Status sub-procedure completes with a timeout result, then the Send Data sub-procedure shall complete with a timeout result.
3. If the Missing Chunks field of any receiver in the Active BLOB Receiver state indicates that some chunks have not been received, then the client shall move back to Step a and continue executing the steps.
4. The client shall remove from the Active BLOB Receiver state every receiver whose Retrieved Transfer Phase field value is not either Waiting For Next Block or Complete.
Pull BLOB Transfer mode
1. The client shall instantiate the Send Data State Machine for each receiver in the Active BLOB Receivers state.
2. The client shall wait until all instantiated Send Data State Machines are in the Final state. When at least one of the instantiated Send Data State Machines has the Result parameter not equal to Failure, then the client shall remove from the Active BLOB Receiver state every receiver whose Send Data State Machine’s Result parameter is equal to Failure. When all of the instantiated Send Data State Machines have the Result parameter equal to Failure, then the Send Block sub-procedure shall complete with a timeout result.

The Send Block sub-procedure completes when any of the following conditions is met:

If the Active BLOB Receivers state is empty, then the Send Block sub-procedure fails.
If the Active BLOB Receivers state contains at least one receiver (i.e., the block transfer completed successfully on at least one receiver), then the Send Block sub-procedure completes successfully.

6.2.4.1. Sending a BLOB Block Start message

To begin the transfer of a block of data, a BLOB Transfer Client shall send a BLOB Block Start message. The response to the BLOB Block Start message is a BLOB Block Status message (see Section 4.7).

6.2.4.2. Send Data State Machine

When the Pull BLOB Transfer mode is used, a BLOB Transfer Client uses the Send Data State Machine to transfer a BLOB to a BLOB Transfer Server.

Figure 6.1 illustrates operation of the Send Data State Machine.

Figure 6.1. Send Data State Machine states, events, event actions, and transitions

The Send Data State Machine defines the Requested Chunks parameter to store a list of the chunks requested by the BLOB Transfer Server. The default value of the Requested Chunks parameter shall be Unknown.

The Send Data State Machine defines the Result parameter to indicate the block transfer status. The Result parameter can be set to Success or Failure.

Table 6.2 defines the initial timer value for the Block Report timer, which is used by the Send Data State Machine to set the maximum interval between transmission of requested chunks.

Timer Name	Initial Timer Value	Description
Block Report	Equation 0. $2 \times T_M B P I + 7 [s e c o n d s]$	The timer defines the interval between two consecutive attempts to receive a BLOB Partial Block Report message.

Table 6.2. Send Data State Machine timers

The default value of the Block Report timer assumes that the LPN polls the friend once per T_MBPI. Under this condition, it takes the LPN two T_MBPI to receive all the chunks sent by the client and send the BLOB Partial Block Report message with the new list of requested chunks. In the calculated value, 7 seconds are added to account for message propagation delay through the network.

Table 6.3 defines the states of the Send Data State Machine.

State	Description
Initial	Initial state of the Send Data State Machine
Waiting For Partial Block Report	Waiting to receive a BLOB Partial Block Report message
Check The Client Timeout Timer	Checking the Client Timeout timer
Prepare Chunks	Preparing requested chunks
Final	Final state of the Send Data State Machine

Table 6.3. Send Data State Machine states

Table 6.4 defines the events that determine the state transitions in the Send Data State Machine and the conditions that generate the events. When the Send Data State Machine state exists, the State Machine shall monitor these conditions. When any condition is met, the corresponding event shall be generated and processed.

Condition	Event
The value of the Requested Chunks parameter is set to the initial value.	Requested Chunks Set To Initial Value
A BLOB Partial Block Report message is received with a non-empty list of requested chunks indicating at least one additional chunk was received compared to the previous BLOB Partial Block Report.	Partial Block Report Received
All requested chunks were prepared.	Chunks Ready
A BLOB Partial Block Report message is received with an empty list of requested chunks.	All Chunks Confirmed
The Block Report timer expired.	Block Report Timer Expired
In the Check The Client Timeout Timer state, the Client Timeout timer is not running.	Timer Expired
In the Check The Client Timeout Timer state, the Client Timeout timer is running.	Timer Active

Table 6.4. Send Data State Machine events

Table 6.5 defines the transitions of the Send Data State Machine and the resulting actions that the node shall execute. Event actions shall be processed during a state transition (i.e., after leaving the current state but before entering a new state).

State	Event	Transition Actions	New State
Initial	Requested Chunks Set To Initial Value	–	Prepare Chunks
Waiting For Partial Block Report	Partial Block Report Received	Stop Block Report timer AND Start the Client Timeout timer from the initial value AND Set Requested Chunks parameter to the value of the Encoded Missing Chunks of the last received BLOB Partial Block Report message	Prepare Chunks
Waiting For Partial Block Report	Block Report Timer Expired	–	Check The Client Timeout Timer
Waiting For Partial Block Report	All Chunks Confirmed	Stop Block Report timer AND Set Result to Success AND Stop the Client Timeout timer	Final
Check The Client Timeout Timer	Timer Active	Send all chunks listed in Requested Chunks parameter AND Start Block Report timer from the initial value	Waiting For Partial Block Report
Check The Client Timeout Timer	Timer Expired	Set Result to Failure	Final
Prepare Chunks	Chunks Ready	Send all chunks listed in Requested Chunks parameter AND Start Block Report timer from the initial value AND Start Client Timeout timer from the initial value	Waiting For Partial Block Report

Table 6.5. Send Data State Machine transitions and actions

6.2.5. Send Data sub-procedure

The Send Data sub-procedure is executed on a BLOB Transfer Client that is operating in Push BLOB Transfer mode to send missing chunks to one or more BLOB Transfer Servers (i.e., receivers).

The Send Data sub-procedure sends all chunks that are indicated as missing by the Missing Chunks field of any receiver in the Active BLOB Receivers state. Chunks need not be sent in ascending order based on the chunk number.

The Send Data sub-procedure consists of the following steps:

The BLOB Transfer Client shall select a chunk that is indicated as missing by the Missing Chunks field of any receiver in the Active BLOB Receivers state.
The client shall send a BLOB Chunk Transfer message with the following configuration:
- The Chunk Number field shall be set to indicate the chunk is being transferred (i.e., the chunk selected in Step 1).
- The Chunk Data field shall be set to the corresponding chunk data.
The Chunk Data field for all chunks except the last chunk shall be the size indicated by the Chunk Size state (i.e., set by the Send Block sub-procedure) (see Section 6.2.4); for the last chunk, the Chunk Data field shall contain all of the remaining bytes of block data, and the size of the Chunk Data field shall be less than or equal to the size indicated by the Chunk Size state.

The BLOB Chunk Transfer message shall be sent to each receiver in the Active BLOB Receivers state that has not yet received the chunk.
The client shall repeat Steps 1 through 2 for each chunk that is indicated as missing by the Missing Chunks field of any receiver in the Active BLOB Receivers state.

When all the missing chunks have been sent, the Send Data sub-procedure completes.

6.2.5.1. Sending a BLOB Chunk Transfer message

To send a chunk from the active block, a BLOB Transfer Client shall send a BLOB Chunk Transfer message. There is no response to this message.

6.2.6. Determine Block Status sub-procedure

The Determine Block Status sub-procedure is executed on a BLOB Transfer Client to determine which chunks are missing from the active block on each receiver.

The Determine Block Status sub-procedure consists of the following steps:

The client shall send a BLOB Block Get message to each receiver in the Active BLOB Receivers state.
The client shall initialize a Client Timeout timer with a timeout set to the output value of the Calculate Client Timeout procedure (see Section 6.2.1).

While the timer is running, the client may repeat the request to the receivers that have not responded with a BLOB Block Status message. The number of request repetitions is implementation specific.

The client shall update the Active BLOB Receivers state by removing the receivers that have responded with a BLOB Block Status message with the value of the Status field not equal to Success. The Missing Chunks value for the corresponding entry in the BLOB Receivers state shall be set to Unknown.

When all receivers have responded and the Active BLOB Receivers state is not empty, then the procedure completes.

When all receivers have responded and the Active BLOB Receivers state is empty, then the procedure fails.

When the timer expires and at least one receiver has responded with the Status field equal to Success, then the procedure completes.

When the timer expires and none of the receivers have responded with the Status field equal to Success, then the procedure completes with a timeout result.

6.2.6.1. Sending a BLOB Block Get message

To query the status of a block transfer, a BLOB Transfer Client shall send a BLOB Block Get message. The response to the BLOB Block Get message is a BLOB Block Status message (see Section 4.7).

6.2.7. Determine Transfer Status procedure

The Determine Transfer Status procedure is executed on a BLOB Transfer Client to get the Transfer Phase state and the Blocks Not Received state of a set of BLOB Transfer Servers.

As inputs, the Determine Transfer Status procedure takes a Multicast Address, an AppKey Index, a Transfer TTL, and a list of unicast addresses identifying the BLOB Transfer Servers whose transfer status is being queried (i.e., the Address List).

As output, the Determine Transfer Status procedure gives a list of BLOB Transfer Servers with their retrieved Transfer Phase state and Blocks Not Received state.

The Determine Transfer Status procedure consists of the following steps:

The BLOB Transfer Client shall send a BLOB Transfer Get message to each BLOB Transfer Server in the Address List input and shall wait for the response.

If the Multicast Address input is the Unassigned address, then the BLOB Transfer Get message shall be sent to each unicast address in the Address List input. If the Multicast Address input is not the Unassigned address, then the message should be sent to the address indicated by the Multicast Address input.
The client shall start a Client Timeout timer from the initial value set to the output value of the Calculate Client Timeout procedure (see Section 6.2.1).

While the timer is running, the client may repeat the request to the receivers that have not responded. The number of request repetitions is implementation specific.

The Determine Transfer Status procedure completes when either of the following conditions is met:

If the list of BLOB Transfer Servers in the output is not empty, then the Determine Transfer Status procedure completes successfully.
If the list of BLOB Transfer Servers in the output is empty, then the Determine Transfer Status procedure fails.

6.2.7.1. Sending a BLOB Transfer Get message

To determine the current state of a BLOB transfer, the BLOB Transfer Client shall send a BLOB Transfer Get message. The response to the BLOB Transfer Get message is a BLOB Transfer Status message (see Section 4.4).

6.2.8. Cancel Transfer procedure

The Cancel Transfer procedure is executed on a BLOB Transfer Client to cancel a BLOB transfer to a set of BLOB Transfer Servers. For example, the procedure can be used to allow a new transfer to start if the previous transfer could not be completed (see Section 5.3.2 and Section 5.3.3).

As input, the Cancel Transfer procedure takes a list of unicast addresses identifying the BLOB Transfer Servers (i.e., the Address List) and a BLOB ID identifying the BLOB.

The Cancel Transfer procedure consists of the following steps:

For each BLOB Transfer Server in the Address List input, the client shall send a BLOB Transfer Cancel message with the BLOB ID field set to the BLOB ID in the input.
- If the BLOB Multicast Address state is the Unassigned address, then the BLOB Transfer Cancel message shall be sent to each unicast address in the Active BLOB Receivers state.
- If the BLOB Multicast Address state is not the Unassigned address, then the BLOB Transfer Cancel message should be sent to the address indicated by the BLOB Multicast Address state.
The client shall start a Client Timeout timer from the initial value set to the output value of the Calculate Client Timeout procedure (see Section 6.2.1).

While the timer is running, the client may repeat the request to the receivers that have not responded. The number of request repetitions is implementation specific.

When all receivers have responded or the timer expires, the Cancel Transfer procedure completes.

6.2.8.1. Sending a BLOB Transfer Cancel message

To cancel the Initialize And Receive BLOB procedure on a BLOB Transfer Server, a BLOB Transfer Client shall send a BLOB Transfer Cancel message. In response to the BLOB Transfer Cancel message, a BLOB Transfer Status message is sent (see Section 4.4).

6.2.9. Get BLOB Receiver procedure

The Get BLOB Receiver procedure is executed on a BLOB Transfer Client to retrieve the status of a transfer to a specified BLOB Transfer Server (receiver).

As input, the Get BLOB Receiver procedure takes the unicast address of the receiver.

As output, the Get BLOB Receiver procedure gives the entry from the BLOB Receivers state for the BLOB Transfer Server identified by the input.

6.2.10. Get Active BLOB Receivers procedure

The Get Active BLOB Receivers procedure is executed on a BLOB Transfer Client to retrieve the list of BLOB Transfer Servers (receivers) that are active in a BLOB transfer.

As output, the Get Active BLOB Receivers procedure gives the list of receivers in the Active BLOB Receivers state.

6.2.11. Get Transfer Progress procedure

The Get Transfer Progress procedure is executed on a BLOB Transfer Client to retrieve the progress of a transfer to a specified BLOB Transfer Server (i.e., receiver).

As input, the Get Transfer Progress procedure takes the unicast address of the receiver.

As output, the Get Transfer Progress procedure gives the percentage of data that has been delivered and confirmed for the BLOB on that receiver. The method for determining that percentage is implementation specific. The calculation should use the values from the Total Blocks state, the Total Chunks state, and the Blocks Not Received field and Missing Chunks field of the BLOB Receivers state.

6.2.12. Receiving a BLOB Transfer Status message

When the BLOB Transfer Client receives a BLOB Transfer Status message, it can determine the Transfer Phase state of the BLOB Transfer Server.

When a BLOB Transfer Client receives a BLOB Transfer Status message from a BLOB Transfer Server, the client shall perform one of the following actions based on the value of the Status field.

Status is success. If the value in the Status field of the BLOB Transfer Status message is Success, then the client shall perform one of the following actions:
- If the server that sent the BLOB Transfer Status message is included in the Active BLOB Receivers state, then the client shall set the corresponding entry in the Active BLOB Receivers state as follows:
  - The client shall set the Status and the Retrieved Transfer Phase in the corresponding entry in the Active BLOB Receivers state to the values of the corresponding fields.
  - If the Blocks Not Received field is present in the BLOB Transfer Status message, then the client shall set the value of the corresponding entry in the Active BLOB Receivers state to the value of the Blocks Not Received field of the message.
- If the server that sent the BLOB Transfer Status message is not included in the Active BLOB Receivers state, and is included in the BLOB Receivers state (i.e., the server was unreachable, or had responded with an error in the Status field of a BLOB Transfer Status message or BLOB Block Status message), then the client may ignore the message. If the client does not ignore the message, then it shall add the server to the Active BLOB Receivers state and shall set the corresponding entry in the Active BLOB Receivers state as follows:
  - The client shall set the Status and the Retrieved Transfer Phase in the corresponding entry in the Active BLOB Receivers state to the values of the corresponding fields.
  - If the Blocks Not Received field is present in the message, then the client shall set the value of the corresponding entry in the Active BLOB Receivers state to the value of the Blocks Not Received field of the BLOB Transfer Status message.
Status is error. If the value of the Status field of the BLOB Transfer Status message is not Success, then the client shall perform one of the following actions:
- If the server that sent the BLOB Transfer Status message is included in the Active BLOB Receivers state, then the client shall remove the receiver from the Active BLOB Receivers state and shall set the corresponding entry in the BLOB Receivers state as follows:
  - The client shall set the Status and the Retrieved Transfer Phase in the corresponding entry of the BLOB Receivers state to the values of the corresponding fields.
  - If the Blocks Not Received field is present in the BLOB Transfer Status message, then the client shall set the value of the corresponding entry in the BLOB Receivers state to the value of the Blocks Not Received field in the message.
  - The client shall set Missing Chunks in the corresponding entry in the BLOB Receivers state to Unknown.
- If the server that sent the BLOB Transfer Status message is not included in the Active BLOB Receivers state, then the client shall ignore the message.

6.2.13. Receiving a BLOB Block Status message

When the BLOB Transfer Client receives a BLOB Block Status message, the BLOB Transfer Client can determine the phase of the transfer. It can determine whether the block was successfully transferred or, if the block was not successfully transferred, which, if any, chunks were missed during the transfer.

When a BLOB Transfer Client receives a BLOB Block Status message from a BLOB Transfer Server, the client shall perform one of the following actions based on the value of the Status field.

Status is success. If the server is not included in the Active BLOB Receivers state, then the client may ignore the BLOB Block Status message.

If the server is not included in the Active BLOB Receivers state, and is included in the BLOB Receivers state (i.e., the server was unreachable, or had responded with an error in the Status field of a BLOB Transfer Status message or BLOB Block Status message), and the client does not ignore the message, then the client shall add the server to the Active BLOB Receivers state.

If the server that sent the message is included in the Active BLOB Receivers state, then the client shall perform one of the following actions based on the value of the Format field of the message.
- BLOB transfer complete. If the block identified by the Block Number field is the last missing block, and either the value of the Format field is No Missing Chunks, or the value of the Format field is Encoded Missing Chunks and the Encoded Missing Chunks field is not present, then the client shall set the entry for the server in the Active BLOB Receivers state as follows:
  - The Status of the entry in the Active BLOB Receivers state shall be set to the value of the Status field of the message.
  - The Retrieved Transfer Phase field of the entry in the Active BLOB Receivers state shall be set to Complete.
  - The Blocks Not Received field of the entry in the Active BLOB Receivers state shall indicate that all blocks have been received.
  - The Missing Chunks field of the entry in the Active BLOB Receivers state shall indicate that all chunks have been received.
- Block transfer complete. If the block identified by the Block Number field is not the last missing block, and either the value of the Format field is No Missing Chunks, or the value of the Format field is Encoded Missing Chunks and the Encoded Missing Chunks field is not present, then the client shall set the entry for the server in the Active BLOB Receivers state as follows:
  - The Status field in the state shall be set to the value of the Status field of the message.
  - The Retrieved Transfer Phase field of the state shall be set to Waiting For Next Block.
  - The Blocks Not Received field in the state shall be set to indicate that the block identified by the Block Number field of the message has been received.
  - The Missing Chunks field in the state shall be set to indicate that the receiver has received all chunks.
- Some chunks missing. If the value of the Format field is Some Chunks Missing, then the client shall set the entry for the server in the Active BLOB Receivers state as follows:
  - The Status field in the state shall be set to the value of the Status field of the message.
  - The Retrieved Transfer Phase field of the state shall be set to Waiting For Next Chunk.
  - The Blocks Not Received field in the state shall be set to indicate that the block identified by the Block Number field of the message has not been received.
  - The Missing Chunks field in the state shall be set to value of the Missing Chunks field of the message.
- Encoded missing chunks. If the value of the Format field is Encoded Missing Chunks, and the Send Data State Machine is not instantiated (see Section 6.2.4.2), then the client shall instantiate a Send Data State Machine, and shall set the Requested Chunks parameter for this State Machine to the value indicated by the Encoded Missing Chunks field in the BLOB Block Status message.
- All chunks missing. If the value of the Format field is All Chunks Missing, then the client shall set the entry for the server in the Active BLOB Receivers state as follows:
  - The Status field in the state shall be set to the value of the Status field of the message.
  - The Retrieved Transfer Phase field of the state shall be set to Waiting For Next Chunk.
  - The Blocks Not Received field in the state shall be set to indicate that the block identified by the Block Number field of the message has not been received.
  - The Missing Chunks field in the state shall be set to indicate that all chunks have not been received.
- Status is error. If the value of the Status field is not Success, and the server is included in the Active BLOB Receivers state, then the client shall remove the server from the Active BLOB Receivers state and shall set the entry for the server in the BLOB Receivers state as follows:
  - The Status field in the state shall be set to the value of the Status field of the message.
  - The other fields of the received message should be ignored.
  - The Missing Chunks field in the state shall be set to Unknown.
  If the value of the Status field is not Success, and the server is not included in the Active BLOB Receivers state, then the client shall ignore the message.

6.2.13.1. Client Timeout timer expiration

When the Client Timeout timer expires for a server, then the client shall remove the server from the Active BLOB Receivers state, and the client shall remove the Send Data State Machine instance corresponding to that server, if such a state machine exists.

7. Message flows and example sequence charts

7.1. Get BLOB transfer capabilities and transfer phase

Figure 7.1 illustrates a sample message exchange between a BLOB Transfer Client and a BLOB Transfer Server where the client checks the Transfer Phase of each server. The BLOB Transfer Client sends a BLOB Transfer Get message to determine whether a BLOB transfer is in progress on the server. If any servers are ready to receive a BLOB, the client then sends a BLOB Transfer Information Get message to these servers to query the BLOB transfer capabilities.

Figure 7.1. Example of selecting nodes for a BLOB transfer

7.2. Starting a BLOB transfer

Figure 7.2 illustrates an example of the messages exchanged between a BLOB Transfer Client and a BLOB Transfer Server when the client starts a BLOB transfer.

Figure 7.2. Example of starting the Transfer BLOB procedure

7.3. Transferring a Block to a BLOB Transfer Server

Figure 7.3 illustrates an example of the messages exchanged between a BLOB Transfer Client and a BLOB Transfer Server when the client starts the Send Block sub-procedure (see Section 6.2.4) to transfer a Block to a server.

Figure 7.3. Example of starting a block transfer

7.4. Transferring chunks: Push mode

Figure 7.4 illustrates an example of the messages exchanged between a BLOB Transfer Client and a BLOB Transfer Server when a client operating in Push BLOB Transfer mode transfers the chunks of a block to BLOB Transfer Servers.

Figure 7.4. Example of transferring chunks of a block in Push BLOB Transfer mode

7.5. Transferring chunks: Pull mode

Figure 7.5 illustrates an example of the messages exchanged between a BLOB Transfer Client and a BLOB Transfer Server when a client operating in Pull BLOB Transfer mode transfers the chunks of a block to a BLOB Transfer Server.

Figure 7.5. Example of transferring chunks of a block in Pull BLOB Transfer mode

7.6. Check block transfer status

Figure 7.6 illustrates an example of the messages exchanged between a BLOB Transfer Client and a BLOB Transfer Server when a client checks the progress of the Send Block sub-procedure (see Section 6.2.4) to determine if any chunks were missed by any of the BLOB Transfer Servers receiving the block.

Figure 7.6. Example of a client identifying missing chunks in Push BLOB Transfer mode

8. Summary

The Assigned Numbers document [3] provides a summary of BLOB transfer messages and models, as follows:

BLOB transfer messages summary: The definitions of messages, and their opcodes, that are available for each of the mesh models
BLOB transfer models summary: All models defined in this specification and their corresponding Model IDs

9. Acronyms and abbreviations

Acronym/Abbreviation	Meaning
BLOB	binary large object
LPN	Low Power node
MTU	maximum transmission unit
PDU	Protocol Data Unit
RFU	Reserved for Future Use
TTL	time to live

Table 9.1. Acronyms and abbreviations

10. References

Bibliography

[1] Mesh Profile Specification, Version 1.0.1

[2] Mesh Protocol Specification, Version 1.1 or later

[3] Bluetooth SIG Assigned Numbers, https://www.bluetooth.com/specifications/assigned-numbers/

Appendix A. Mathematical functions

This appendix provides the definitions of mathematical functions used in this specification.

A.1. Ceil function

The ceil(x) function returns the smallest integer greater than or equal to x.

A.2. Floor function

The floor(x) function returns the largest integer less than or equal to x.

A.3. Min function

The min(x, y, …) function returns the smallest value from a set of inputs.

A.4. Max function

The max(x, y, …) function returns the largest value from a set of inputs.

A.5. Modulo function

The modulo(x, y) function returns the remainder after division of x by y.

A.6. Log2 function

The log2(x) function returns the binary logarithm of x.

Mesh Binary Large Object Transfer Model

Bluetooth® Specification

Version History

Acknowledgments

1. Introduction

1.1. Language

1.1.1. Language conventions

1.1.1.1. Implementation alternatives

1.1.1.2. Discrepancies

1.1.2. Reserved for Future Use

1.1.3. Prohibited

1.2. Table conventions

1.2.1. Requirements that are in a table

1.2.2. Indicating a cell that has no value or content

1.3. Architectural concepts

Note

1.3.1. Unknown state value

1.3.2. Internal state

1.4. Error handling

1.5. Bluetooth specification release compatibility

1.6. Conformance

1.7. Terminology

2. BLOB transfer introduction

2.1. BLOB transfer process overview

Note

3. BLOB Transfer states

3.1. States used by both BLOB Transfer models

3.1.1. BLOB

3.1.1.1. BLOB ID

3.1.1.2. BLOB Size

3.1.1.3. Block Size Log

3.1.1.4. BLOB Data

3.1.1.5. Total Blocks

3.1.2. BLOB Block

3.1.2.1. Block Number

3.1.2.2. Current Block Size

3.1.2.3. Chunk Size

3.1.2.4. Total Chunks

3.1.2.5. BLOB Block Data

3.1.3. Transfer TTL

3.1.4. Transfer Mode

3.1.4.1. Binding with the Transfer Phase state

3.2. BLOB Transfer Server states

3.2.1. Transfer Phase

3.2.2. Expected BLOB ID

3.2.3. Blocks Not Received

3.2.4. Missing Chunks

3.2.5. Client MTU Size

3.2.6. Server Timeout Base

3.2.7. Capabilities

3.2.7.1. Min Block Size Log

3.2.7.2. Max Block Size Log

3.2.7.3. Max Total Chunks

3.2.7.4. Max Chunk Size

3.2.7.5. Max BLOB Size

3.2.7.6. Server MTU Size

3.2.7.7. Supported Transfer Mode

3.3. BLOB Transfer Client states

3.3.1. BLOB Receivers

3.3.2. Active BLOB Receivers

3.3.3. BLOB Receivers Capabilities

3.3.4. BLOB Multicast Address

3.3.5. AppKey Index

3.3.6. Client Timeout Base

3.4. Summary of status codes

4. BLOB Transfer messages

4.1. BLOB Transfer Get

4.2. BLOB Transfer Start

4.3. BLOB Transfer Cancel

4.4. BLOB Transfer Status

4.5. BLOB Block Get

4.6. BLOB Block Start

4.7. BLOB Block Status

4.8. BLOB Partial Block Report

4.9. BLOB Chunk Transfer

4.10. BLOB Information Get

4.11. BLOB Information Status

5. BLOB Transfer Server model

5.1. Description

5.2. Procedures

Bluetooth^® Specification