Interface AnnounceOtaProviderRequest

This field shall contain a value expressing the reason for the announcement.

This field shall contain the endpoint number which has the OTA Provider device type and OTA Software Update Provider cluster server on the ProviderNodeID. This is provided to avoid having to do discovery of the location of that endpoint by walking over all endpoints and checking their Descriptor Cluster.

When Generated

An OTA Provider may invoke this command directly to an OTA Requestor, to announce its presence as an OTA Provider on the Fabric.

These announcements, if made, SHOULD be made at most once every 24 hours for any given target Node, to assist OTA Requestors in discovering available OTA Provider resources, unless the AnnouncementReason is UrgentUpdateAvailable, in which case this command may be more frequent.

Any invocation shall be made with a delay of at least 1 second between invocations from a given OTA Provider, to reduce burden on the networking infrastructure and affect a form of serialized jitter. It is recommended to offset the first announcement of a round (i.e. new set of announcements after a previous complete set) by a random delay time with a distribution span of >= 60 seconds to jitter announcement schedules over time.

Effect on Receipt

On receipt of this command, an OTA Requestor SHOULD consider the new ProviderNodeID and AnnouncementReason to possibly query for new software sooner than it would have with its default behavior.

The OTA Requestor SHOULD NOT update entries in the DefaultOTAProviders list based on announcements.

The receiving Node may ignore the content of the announcement if it is unable or unwilling to further query OTA Providers temporarily, or if its provider list is full. If the announcement is ignored, the response SHOULD be SUCCESS.

Depending on the value of the AnnouncementReason field, the OTA Requestor may have to query the OTA Provider. See Section 11.20.7.6.1.3, “AnnouncementReason Field” for the different values and their meaning.

If present, the MetadataForNode field’s may be used by a receiving OTA Requestor in any way it deems satisfactory. The MetadataForNode field SHOULD be empty under most normal operational circumstance, but can be useful in environments such as field trials or integration test environments to hint at additional capabilities which OTA Requestors may use in a particular Vendor-specific context.

This optional field, if present, shall consist of a top-level anonymous list; each list element shall have a profile-specific tag encoded in fully-qualified form. Each list element shall contain a manufacturer-specific payload, which the Node invoking this command wants to expose to the receiving Node. This payload may be used for any purpose and SHOULD be as small as practical, especially if invoked to groups, in order to reduce networking burden of these payloads.

This field SHOULD only be included if the sending OTA Provider has knowledge that some recipient can make use of it.

This field shall contain the Node ID of a Node implementing the OTA Provider cluster server, on the accessing fabric.

This field shall contain the assigned Vendor ID of the Node invoking this command, as it would appear in that Node’s Basic Information Cluster VendorID attribute.