Subscriptionsare used to report Notificationsto the Client. Their general behaviour is summarized below. Their precise behaviour is described in

  1. Subscriptionshave a set of MonitoredItemsassigned to them by the Client. MonitoredItemsgenerate Notificationsthat are to be reported to the Clientby the Subscription(see 5.12.1for a description of MonitoredItems).
  2. Subscriptionshave a publishing interval. The publishing interval of a Subscriptiondefines the cyclic rate at which the Subscriptionexecutes. Each time it executes, it attempts to send a NotificationMessageto the Client. NotificationMessagescontain Notificationsthat have not yet been reported to Client.
  3. NotificationMessagesare sent to the Clientin response to Publishrequests. Publishrequests are normally queued to the Session as they are received, and one is de-queued and processed by a Subscriptionrelated to this Sessionfor each publishing cycle, if there are Notificationsto report. When there are not, the Publishrequest is not de-queued from the Session, and the Serverwaits until the next cycle and checks again for Notifications.
  4. At the beginning of a cycle, if there are Notificationsto send but there are no Publishrequests queued, the Serverenters a wait state for a Publishrequest to be received. When one is received, it is processed immediately without waiting for the next publishing cycle.
  5. NotificationMessagesare uniquely identified by sequence numbers that enable Clientsto detect missed Messages. The publishing interval also defines the default sampling interval for its MonitoredItems.
  6. Subscriptionshave a keep-alive counter that counts the number of consecutive publishing cycles in which there have been no Notificationsto report to the Client. When the maximum keep-alive count is reached, a Publishrequest is de-queued and used to return a keep-alive Message. This keep-alive Messageinforms the Clientthat the Subscriptionis still active. Each keep-alive Messageis a response to a Publishrequest in which the notificationMessageparameter does not contain any Notificationsand that contains the sequence number of the next NotificationMessagethat is to be sent. In the clauses that follow, the term NotificationMessagerefers to a response to a Publishrequest in which the notificationMessageparameter actually contains one or more Notifications, as opposed to a keep-alive Messagein which this parameter contains no Notifications. The maximum keep-alive count is set by the Clientduring Subscriptioncreation and may be subsequently modified using the ModifySubscription Service. Similar to Notificationprocessing described in (c) above, if there are no Publishrequests queued, the Serverwaits for the next one to be received and sends the keep-alive immediately without waiting for the next publishing cycle.
  7. Publishing by a Subscriptionmay be enabled or disabled by the Clientwhen created, or subsequently using the SetPublishingMode Service. Disabling causes the Subscriptionto cease sending NotificationMessagesto the Client. However, the Subscriptioncontinues to execute cyclically and continues to send keep-alive Messagesto the Client.
  8. Subscriptionshave a lifetime counter that counts the number of consecutive publishing cycles in which there have been no Publishrequests available to send a Publishresponse for the Subscription. Any Servicecall that uses the SubscriptionIdor the processing of a Publishresponse resets the lifetime counter of this Subscription. When this counter reaches the value calculated for the lifetime of a Subscriptionbased on the MaxKeepAliveCount parameter in the CreateSubscription Service(5.13.2), the Subscriptionis closed. Closing the Subscriptioncauses its MonitoredItemsto be deleted. In addition the Servershall issue a StatusChangeNotification notificationMessagewith the status code Bad_Timeout. The StatusChangeNotification notificationMessagetype is defined in 7.25.4.
  9. Sessionsmaintain a retransmission queue of sent NotificationMessages. NotificationMessagesare retained in this queue until they are acknowledged. The Sessionshall maintain a retransmission queue size of at least two times the number of Publishrequests per Sessionthe Serversupports. A Profilein OPC 10000-7may make the retransmission queue support optional. The minimum number of Publishrequests per Sessionthe Servershall support is defined in OPC 10000-7. Clientsare required to acknowledge NotificationMessagesas they are received if the Publishresponse parameter availableSequenceNumbersis not an empty array. An empty array in availableSequenceNumbersindicates that the Serverdoes not support a retransmission queue and acknowledgement of NotificationMessages. In the case of a retransmission queue overflow, the oldest sent NotificationMessagegets deleted. If a Subscriptionis transferred to another Session, the queued NotificationMessagesfor this Subscriptionare moved from the old to the new Session.

The sequence number is an unsigned 32-bit integer that is incremented by one for each NotificationMessagesent. The value 0 is never used for the sequence number. The first NotificationMessagesent on a Subscriptionhas a sequence number of 1. If the sequence number rolls over, it rolls over to 1.

When a Subscriptionis created, the first Messageis sent at the end of the first publishing cycle to inform the Clientthat the Subscriptionis operational. A NotificationMessageis sent if there are Notificationsready to be reported. If there are none, a keep-alive Messageis sent instead that contains a sequence number of 1, indicating that the first NotificationMessagehas not yet been sent. This is the only time a keep-alive Messageis sent without waiting for the maximum keep-alive count to be reached, as specified in (f) above.

A Clientshall be prepared for receiving Publishresponses for a Subscriptionmore frequently than the corresponding publishing interval. One example is the situation where the number of available notifications exceeds the Subscriptionsetting maxNotificationsPerPublish. A Clientis always able to control the timing of the Publishresponses by not queueing Publishrequests. If a Clientdoes not queue Publishrequests in the Server, the Servercan only send a Publishresponse if it receives a new Publishrequest. This would increase latency for delivery of notifications but allows a Clientto throttle the number of received Publishresponses in high load situations.

The value of the sequence number is never reset during the lifetime of a Subscription. Therefore, the same sequence number shall not be reused on a Subscriptionuntil over four billion NotificationMessageshave been sent. At a continuous rate of one thousand NotificationMessagesper second on a given Subscription, it would take roughly fifty days for the same sequence number to be reused. This allows Clientsto safely treat sequence numbers as unique.

Sequence numbers are also used by Clientsto acknowledge the receipt of NotificationMessages. Publishrequests allow the Clientto acknowledge all Notificationsup to a specific sequence number and to acknowledge the sequence number of the last NotificationMessagereceived. One or more gaps may exist in between. Acknowledgements allow the Serverto delete NotificationMessagesfrom its retransmission queue.

Clientsmay ask for retransmission of selected NotificationMessagesusing the Republish Service. This Servicereturns the requested Message.

Subscriptionsare designed to work independent of the actual communication connection between OPC UA Clientand Serverand independent of a Session. Short communication interruptions can be handled without losing data or events. To make sure that longer communication interruptions or planned disconnects can be handled without losing data or events, an OPC UA Servermay support durable Subscriptions. If this feature is supported, the Serveraccepts a high Subscription RequestedLifetimeCountand large MonitoredItem QueueSizeparameter settings. Subclause 6.8describes how durable Subscriptionscan be created and used.