Device Time Service

If the Server supports the E2E-CRC feature, the value of the E2E_CRC field shall be calculated over all data fields except for the E2E_CRC field itself (for details regarding CRC calculation, see Section 2.3 of [3]). If the Server does not support the E2E-CRC feature, the E2E_CRC field of the DT Feature characteristic shall be set to 0xFFFF.

The bits of the DT_Features field may either be static for the lifetime of the device or static only during a connection. If enabled for indications, any change to the value of the DT_Features field shall be indicated by the Server to bonded Clients.

If a feature is supported, the corresponding bit position is set to 1 in the DT_Features field. If a feature is not supported, the corresponding bit position is set to 0.

If the service supports the E2E-CRC feature, the DT Parameters characteristic shall include an E2E_CRC field the value of which is calculated over all data fields except for the E2E_CRC field itself (see [3] for details).

The RTC_Resolution field describes the RTC resolution in fractions of a second. The Server shall populate this field with the value for the resolution of the Server’s RTC. The Server may declare the RTC resolution to the closest fractional-second resolution, as represented by 1/65536^th of a second. When the server’s RTC resolution is less than 1/65536 of a second, the server may declare the minimum RTC_Resolution of 1/65536 of a second.

An RTC_Resolution example for a shock sensing device having 5 ms of RTC_Resolution would report a value of (0.005 s) * (65536 counts/s) = 327.7 counts ~ 328 counts. Alternatively, the RTC_Resolution example for a glucose meter utilizing an internal clock frequency of 32.768 kHz, but where the device’s software only tracks a 1-second resolution in regard to reporting time values, would show an RTC_Resolution value of 0xFFFF (65535 x 1/65536 = 0.99998 = ~1.0000).

The range of RTC_Resolution includes the value 0, which is defined as RTC_Resolution is an unknown number of fractions of a second.

When the Server supports the RTC Drift Tracking feature, the Max_RTC_Drift_Limit field shall contain the value in seconds used by the Server to determine whether the Base_Time of the device’s RTC might have drifted enough to cause a loss of time source synchronization and if aligned to UTC, loss of UTC alignment (see Section 3.3.1.7).

When the Server supports the RTC Drift Tracking feature, the Max_Days_Until_Sync_Loss field is a static value that shows the maximum amount of time in days that a Server can continuously run without a Time Update procedure from a qualified time source before the Server shall declare loss of synchronization with the time source, and if previously UTC aligned, loss of UTC alignment. The Max_Days_Until_Sync_Loss value is determined by the RTC’s worst-case frequency drift applied over time until the Max_RTC_Drift_Limit is reached (see Section 3.3.1.5.2).

The Non_Logged_Time_Adjustment_Limit field contains the value used by the Server to determine whether a Base_Time change is to be logged. When the Server supports Time Change Logging, the Non_Logged_Time_Adjustment_Limit field shall be used to avoid the logging of trivial time changes caused by Time Update procedures with very small-time value changes.

Implementations may configure the value of this limit so that the Server logs all Time_Update events regardless of how small the time change is. In these implementations, the value of the Non_Logged_Time_Adjustment_Limit field is set to zero. A Server that sets the Non_Logged_Time_Adjustment_Limit field to zero may still choose to consolidate Time Update procedures and reveal those Base_Time adjustments in the Report Active Time Adjustments procedure, and these adjustments will eventually become a Time_Update event log type (see Section 3.4.1.1.1.1).

As Appendix A.1 indicates, the Non_Logged_Time_Adjustment_Limit should be a small fraction of the amount of time that would cause the Server to indicate that the time synchronization with the time source was lost, that is, when the Accumulated_RTC_Drift reaches the Max_RTC_Drift_Limit.

If the Server supports the Propose Non_Logged_Time_Adjustment_Limit feature, then Server allows an authorized Client to change the value of this field (see Sections 3.7.1.1.2 and 3.7.2.4 ).

See Appendix A.2 for a discussion regarding implementing non-logged time adjustments.

When the Displayed Formats feature is supported, the Server uses the Displayed_Formats field to declare the device’s format for displaying the date and time on the device.

The Server shall populate the Displayed_Formats field with the appropriate values from Table 3.5.

Support for the Displayed Formats feature is not the same as the International Organization for Standardization (ISO) standard for the representation of dates and times (ISO 8601). The ISO 8601 standard outlines the representation of dates and times in the transport of these data structures and not the displayed representation of date and time. Implementations of the DTS that use the Displayed_Formats table should be consistent when displaying a measurement with data and time formatting as when displaying date and time formatting without a displayed measurement value. The Server shall display the date and time format as revealed to the user at the time that a user would observe the measurement.

See Appendix A.3 for more information regarding Displayed_Formats.

The Date Field Separator defined in Table 3.5 is shown as a period when used in the Displayed Date Format definitions row; using a period in these Displayed Date Format definitions is only for showing the order of elements within the displayed Date Field of the Server device. For example, the representation shown for the Displayed Date Format of 0x01 = MM.DD.YY in row 1 as “12.31.16” could have been represented in the table as “12/31/16.”

If the Server supports the E2E-CRC feature, the DT characteristic shall include an E2E_CRC field the value of which is calculated over all fields except for the E2E_CRC field itself (see [3] for details).

The Base_Time field represents the seconds since midnight of January 1, 1900 (00:00:00.0000 on January 1, 1900) when the DT_Status flag for Epoch Year 2000 is set to 0. When the DT_Status flag for Epoch Year 2000 is set to 1; then the Base_Time field represents the seconds since January 1, 2000; 00:00:00.

Base_Time should not be confused with User_Time (see Section 3.3.1.6), which describes the time that a device user would see on a display. Base_Time is a continuous timeline that describes the reference or UTC time and does not include local offsets of Time_Zone and DST_Offset.

A device may allow a user to set the Base_Time value, for example, after a time fault, to provide time initialization values (see Section 3.3.1.5.1.1).

The range of valid Base_Time values is implementation-specific, and the server may restrict the range of Base_Time values for each supported epoch year.

See Section 3.7.1.1.1.2 regarding Time Update procedures and the Base_Time values used in those procedures.

The Time_Zone field shall have the same formatting as defined by the Time Zone characteristic described in [3]. When this specification mentions local time adjustments for Time_Zone, those local adjustments to Base_Time are defined by the Time Zone characteristic.

The DST_Offset field shall have the same formatting as defined by the DST Offset characteristic described in [3]. When this specification mentions local time adjustments for DST, those adjustments to Base_Time are defined by the DST Offset characteristic.

The Device Time Status (DT_Status) field reveals the status of the current DT characteristic. The DT_Status bits are defined in Table 3.7.

Sections 3.3.1.5.1 to 3.3.1.5.7 describe the behaviors of the flags in the DT_Status field. Although the DT_Status field is a bit field, some combinations of flags are not allowed. For example, the UTC Aligned flag should never be set when the Time Fault flag is set.

If the Separate User Timeline feature is supported, then the value of the User_Time field represents the number of seconds since the epoch date as declared in the Epoch Year 2000 DT_Status flag, which reflects the device’s displayed user-facing time.

The purpose of User_Time is to allow full flexibility for a device user to adjust the time of the device while maintaining the device’s synchronization with a time source.

The User_Time is a time that does not attempt to categorize local time information into time zone and DST offset values. The Server should preserve the values for local information of Time_Zone_Update and DST_Offset_Update as obtained from Time Update procedures. If a device user can view and select Time Zone and DST Offset values, then these local values from a Time Update procedure may be directly overwritten by the user during a user time-setting action on the device.

For a Server that supports the Separate User Timeline feature, the Separate User Timeline is revealed by the behavior of the device to allow a user to adjust the user-facing time of the device at times beyond initialization and at the will of the user. For example, sometime after startup, the Server has had the opportunity to synchronize with a Client and the Server has been aligned with a time reference. The device’s user interface allows the user to adjust the time of the device. This creates a parallel time to the synchronized time reference. To preserve the synchronized Base_Time value, the user has created a User_Time that now becomes the user-facing time. Regardless of any change the device user makes to user-facing time, DTS can maintain a synchronized Base_Time value to facilitate a continuous timeline for stored data.

When a user can set the time of the device through the user interface, the application may limit the range of values to which a user can adjust the User_Time value. This specification does not address application limits placed on User_Time values. Regardless of the time value that is set by the user. The User_Time shall reflect the value that the user would see displayed on the device. User_Time is necessary to provide context for stored data.

Whether a device chooses to synchronize the User_Time with values received from a time source during a Time Update procedure is implementation-specific.

For Servers that do not support the Separate User Timeline feature, the device user may be allowed to enter time values on first installment of the battery or after a time fault, but this action alone is not support for a Separate User Timeline. For this type of Server, the first Time Update that provides time synchronization with a time reference and may, depending on the implementation, correct any user-induced time value “mistakes” and adjust the Server’s Base_Time and local offsets (Time_Zone and DST_Offset), and the User_Time is not used (User_Time field is excluded).

The time value loaded into User_Time after a time fault may synchronize to the just re-initialized current time values (Base_Time with local offsets), or the User_Time may attempt to hold the previous timeline offset from the re-initialized time values. The details of re-initialization time values for Base_Time and User Time are implementation details (see Section 3.3.1.5.1.1).

See Appendix A.4 for an example of the Server’s calculations for the User_Time field.

When the Server supports the RTC Drift Tracking feature, the Server shall calculate the Accumulated_RTC_Drift value before sending an indication or responding to a read characteristic value request of the DT characteristic so that the Server reports the current accumulated drift value. The Server shall not indicate the DT characteristic solely based on normal progression of this field that is attributable to the calculated worst-case drift of the RTC (see Section 3.2.1.4).

The Accumulated_RTC_Drift field represents the present amount of accumulated drift (absolute value) in seconds that the RTC may have drifted from a qualified synchronized source since the last synchronization event. Accumulated_RTC_Drift is the worst-case RTC drift rate over a given time span.

The worst-case RTC drift rate is not revealed by any field in the DTS, but its value can be calculated from the DT Parameters that are directly affected by the worst-case RTC drift rate. These DT Parameters are Max_Days_Until_Sync_Loss and Max_RTC_Drift_Limit.

The Accumulated_RTC_Drift can be calculated by the Server based on the value of the DT Parameters for Max_RTC_Drift_Limit divided by the Max_Days_Until_Sync_Loss the Max_RTC_Drift_Limit, and if the Server was synchronized and aligned to UTC, then the Server is considered as still synchronized to the Time_Source and aligned to UTC, if previously aligned (see Appendix A.1).

If the Accumulated_RTC_Drift reaches the Max_RTC_Drift_Limit without a Time Update procedure, and the Server supports the Time Change Logging feature, then the Server logs the Max_RTC_Drift_Limit_Reached event (see Section Section 3.4.1.1). The Server shall continue to add to the Accumulated_RTC_Drift value until a Time Update procedure corrects the Server’s Base_Time and clears the Accumulated_RTC_Drift by setting its value to 0 (see Section 3.7.1.1.1).

If the Accumulated_RTC_Drift reaches Max_RTC_Drift_Limit as detected by the Server during a Time Update procedure, and the Server supports the Time Change Logging feature, then the Server shall create a separate Max_RTC_Drift_Limit_Reached event using the time values from the Time Update, shall store the Accumulated_RTC_Drift with the log entry, shall clear the Accumulated_RTC_Drift value of the DT characteristic, and shall create a separate time change event log for the just received Time Update values.

If the Accumulated_RTC_Drift reaches the Max_RTC_Drift_Limit, the Server shall clear the UTC Aligned bit of the DT_Status field by setting this bit to 0 (see Section 3.3.1.5.2). The Server should also set the Propose Time Update bit of the DT_Status field to indicate its desire to obtain a Time Update from connected Clients. If not connected, the Server should become connectable if it detects RTC drift such that the Accumulated_RTC_Drift exceeds or almost exceeds the Max_RTC_Drift_Limit specified in the DT Parameters characteristic and the DT characteristic is configured for indications. This allows a Client to connect and improve the Server’s time quality using a Time Update procedure.

If the Accumulated_RTC_Drift reaches the full value of the field’s range (0xFFFF), the Server locks this value of the Accumulated_RTC_Drift (at 0xFFFF) until the Server accepts a Time Update procedure and begins a synchronization with a time source.

When a time synchronization event that adjusts the Base_Time occurs, the Server shall clear the Accumulated_RTC_Drift field (set the value to 0), and the Accumulated_RTC_Drift will once again begin to accumulate the worst-case clock drift since the synchronization event.

When the Server supports the Time Change Logging feature, this field shall hold the Sequence_Number of the next to-be-logged time change event so that connecting Clients can readily determine whether time change events have occurred on the Server since the last connection. See Section 3.4.1.5 for more information on record numbering within the Time Change Log Data characteristic.

When the Server supports the Base Time Second-Fractions feature the Base_Time_Second_Fractions field shall represent the Base Time fractions of a second of the synchronized time source in 1/65,536 seconds.

The Server creates log entries for the following time change event log types (events) when the Time Change Logging feature is supported:

The Server may combine events of the same event log type into a single log entry for Time_Updates or Time_Faults if no stored data is affected by combining those same-event log types. The fields within the Time_Change_Log_Data_Record field that the Server includes in a record for a given event type are itemized in Table 3.10.

The Segmentation_Header field structure is shown in Table 3.9.

When a Time Change Log Data characteristic notification fits within a single ATT_MTU-3 message size, the notification consists of a single message with a Segmentation_Header indicating both the First Segment bit and the Last Segment bit set to 1, otherwise multiple message segments are necessary for the complete notification of that particular Time Change Log Data characteristic.

For each RACP request, the Server may initialize the Rolling Segment Number with a value as determined by the application. The Rolling Segment Number shall increment with each notification segment that is sent by the Server. When the Rolling Segment Number is equal to 63, and the Server has more segments to send to complete the RACP request, the counter shall roll over to 0 with the sending of the next consecutive notification segment.

Section 3.4.1.2.1 describes how multiple message segments are created when the notification size exceeds ATT_MTU-3 octets.

3.4.1.2.1. Time Change Log Data characteristic segmentation

The construction of notifications of the Time Change Log Data characteristic depends on the agreed ATT_MTU size and the size of the notifications as determined by the included Event_Log_Flags fields of the Time Change Log Data notification. When the Server is processing an RACP request for records, the Server shall include the Segmentation_Header octet at the start of each Time Change Log Data notification with the record following with the fields of the record formatted as described in Table 3.10. Depending on the size of the record, as determined by the Server configuration and the event log type, the Time Change Log Data notification may consist of a single notification or several notifications. The record start and stop indicators of First Segment and Last Segment respectively, along with the Rolling Segment Counter, are used to delineate individual notification segments of a particular record within a stream of notifications and the segment order of the data stream.

Regarding the reporting of individual records, if the size of the Time Change Log Data characteristic record to be notified is greater than ATT_MTU-3, it is necessary to send multiple notifications to send the complete record. A Server that wants to optimize the sending of records should negotiate with the connected Client the MTU size that will accommodate the maximum record length for the Server’s features as revealed by Table 3.8 and Table 3.10.

For example, a Server that supports all DT Features from Table 3.3 could request an MTU size of 49 octets and have enough payload space for the largest Time Change Log Data characteristic notification consisting of an ATT notification header, a Segmentation_Header, and a Time_Change_Log_Data_Record field [(3+ 1 + 45) octets] (see Table 3.11).

The number of notifications that needs to be sent for each record can be calculated by dividing the size of the record to be transported by ATT_MTU-3 rounded up to the nearest integer, N, as represented in the steps below.

Responding to RACP requests:

1. The Server sends the records to be notified based on the RACP Request Opcode and Operand (see Section 3.8).

2. The Server checks the size of the record to be notified.

   1. If N=1, the First Segment and Last Segment bits of the Segmentation_Header field shall both be set to 1. The Rolling Segment Counter is set to one greater than the counter value sent with the last notification and the record is notified.

   2. If N>1, the First Segment bit of the Segmentation_Header field shall be set to 1 and the Last Segment bit shall be set to 0, and up to ATT_MTU-3 octets of the record to be transported shall be sent in this message segment to optimize the notification.

      1. The Server continues to send notification segments of this record with the First Segment bit set to 0 and increments the Rolling Segment Counter with each notification segment until the last notification of the record in which the Segmentation_Header sets the Last Segment bit to 1.

3. Are there more records to send for this RACP request?

   1. If YES, return to step 2 for the next record to be notified.

   2. If NO, end the procedure by sending the RACP Response Code indication.

Figure 3.1 shows the construction of the Time Change Log Data notifications when a series of records consisting of numerous notifications are sent due to an RACP request and some of the requested records are greater than the ATT_MTU-3 size limitation.

Figure 3.1. Example Series of Time Change Log Data notifications

Table 3.10 shows the structure of the Time_Change_Log_Data_Record field used as part of the Time Change Log Data characteristic to notify time change events.

The size of the Active_Time_Adjustments field is increased by 4 octets to 11 octets when the Base Time Second-Fractions feature is supported (see Table 3.13).

The Time_Change_Log_Data_Record field may be 14 to 45 octets (see Table 3.11).

Table 3.11 shows the minimum and maximum Time_Change_Log_Data_Record field size based on the time change event log type and the supported features.

If the service supports E2E-CRC, each Time_Change_Log_Data_Record field includes an E2E_CRC field the value of which is calculated over all data fields except for the E2E_CRC field itself (see [3] for details).

The Sequence_Number field shall be included in the Time_Change_Log_Data_Record. The Sequence number is an unsigned integer that begins with the value 0 and increments for each logged event. When the Sequence_Number reaches 0xFFFF, it wraps back to 0x0000. The size of the time change event log is implementation-specific, and the oldest log entries shall be overwritten with the newest log entries when the time change event log reaches its maximum size.

The value of the Next_Sequence_Number field within the DT characteristic is always one greater than the value of the Sequence_Number field contained in the most recent log entry of Time_Change_Log_Data_Record.

The Event_Log_Type field shall be included in the Time_Change_Log_Data_Record. The Event_Log_Type field facilitates type filtering by Clients that collect records and defines the included fields of the record (event log type) to only those fields shown in Table 3.10.

The Event_Log_Flags field shall be used by the Server to signal which of the fields within the Time_Change_Log_Data_Record field are included in a specific event log type. When a bit in the flag field is set to 1, each notification shall include and populate the respective field with the appropriate value for that log entry.

See the first column of Table 3.10 for the requirements on the fields within the Time_Change_Log_Data_Record field that are conditional based on the type of time change event.

The DT_Status field as defined in Section 3.3.1.5 shall accurately represent the Server’s time status when the Server logs the new time change event.

The DT_Status_Old field contains the DT_Status value that the Server had in affect just before the event that caused the log entry to be created.

The RTC_Time_Fault_Counter reveals the total number of time faults that has occurred on the device. The RTC_Time_Fault_Counter is a mandatory field for all log entries due to the negative impact of time faults on device time and timestamped data. The value of this field should be initialized to 0 to facilitate detection of a faulty device clock.

This field is incremented after logging a singular Time_Fault event or if the Server is consolidating Time_Fault events, then the value of the RTC_Time_Fault_Counter field is increased by the amount of the Consolidated_Log_Counter when the time fault consolidation is completed and logged (see Section 3.4.1.1.1.1).

The Time_Zone field shall contain the new value at the time of the log entry. For formatting of this field, see Section 3.3.1.3.

The DST_Offset field shall contain the new value at the time of the log entry. For formatting of this field, see Section 3.3.1.4.

The Time_Source field shall have the same formatting as defined by the Time Source characteristic described in [3]. This field reveals the time source of the time values used for the time of the Time_Update event. When the log entry is the result of a time fault, and the Server does not have immediate access to a time source to re-initialize the Server’s time values to a qualified source, the Server shall record the time fault as having a Time_Source of Manual in the case where the user approves the time, or as Unknown in the case where a user does not approve the re-initialized time.

The Time_Accuracy field shall have the same formatting as defined by the Time Accuracy characteristic described in [3]. This is the Client’s accuracy of the Base_Time value at the time of the update.

When a Server logs a Time_Update event or logs a Time_Fault event with a Time_Source of Manual or Unknown, the Server shall log the value of Time_Accuracy as Unknown (0xFF) (see [3]).

When the log entry is the result of a Time Update procedure, the Base_Time field shall always represent the time value received from a Time Update procedure regardless of whether the Server is consolidating Base_Time adjustments. The format of this field is the same as the format of the Base_Time field as defined in the DT characteristic.

When the log entry is the result of a time fault or is a consolidated time fault, the Base_Time field contains the Base_Time initialization value of the Server, which is implementation-specific (see Section 3.3.1.5.1.1).

When the log entry is not a result of a Base_Time change, the Base_Time field (and the Base_Time_Old field) represents the Server’s Base_Time at the moment of an event that required logging (for example, the user changed the User_Time by adjusting the device’s clock, or the user made a change to the Displayed_Formats).

Also refer to Section 3.4.1.16 for additional information about Base_Time for consideration regarding consolidated logging, accumulated RTC drift, or Accumulated Non-Logged Time Adjustments.

This field stores the Server’s present Base_Time in seconds at the time of a Time Update procedure, unless the log entry contains non-logged or consolidated Base_Time changes (see Section 3.4.1.1.1.2). The format of this field is the same as the format of the Base_Time field as defined in the DT characteristic.

When not consolidating time changes, a Server that accepts local Time Update values but rejects the Base_Time value shall use the same Base_Time value for both the Base_Time and Base_Time_Old fields to indicate that the Base_Time did not change and the Server shall also use the appropriate Rejection Flag during such Time Updates (see Table 3.22).

When the Server is consolidating time changes, and the Server accepts local Time Update values but rejects the Base_Time value, the Server shall retain the value of the Base_Time_Old to the value of the first Time Update that resulted in this consolidated record, and the Server shall also use the appropriate Rejection Flag during such consolidated Time Updates.

When the log entry is the result of an accumulation of Time Updates where the non-logged time adjustments exceeded the Non_Logged_Time_Adjustment_Limit, this field reveals the value of the Base_Time before the first Time Update adjusted the Base_Time below the Non_Logged_Time_Adjustment_Limit.

The Accumulated_RTC_Drift field represents the Accumulated_RTC_Drift at the time of the event being logged. This is the accumulated drift value since the last Time Update procedure where the Base_Time has been accepted by the Server. The Accumulated_RTC_Drift field has the same format as defined in the DT characteristic.

The User_Time field holds the value for the new user-facing time that the user adjusted the time to. The User_Time field is the same as defined in the DT characteristic.

The User_Time_Old field represents the user-facing time before the user made an adjustment to the User_Time. The format of this field is the same as the User_Time field as defined in the DT characteristic.

When the Base_Time_Second_Fractions are supported by the Server, the Base_Time_Second_Fractions field is as defined for the DT characteristic and represents the new Base_Time_Second_Fractions of the log entry due to a time change event. The Base_Time_Second_Fractions value is the value of the Base_Time_Second_Fractions_Update accepted during a Time Update procedure or the value of Base_Time_Second_Fractions loaded by the Server at the moment of an event that required logging (see Section 3.4.1).

When the Server supports the Base Time Second-Fractions feature, the Base_Time_Second_Fractions_Old field shows the value of the Server’s Base_Time_Second_Fractions at the time of a Time Update or time re-initialization and follows the rules for Base_Time (see Section 3.3.1.5.1.1). The format of this field is the same as the format for the Base_Time_Second_Fractions.

When the Server supports the Propose Non-Logged Time Adjustment Limit feature, the Non_Logged_Time_Adjustment_Limit field reveals the new value after the change to the Non_Logged_Time_Adjustment_Limit. This field has the same format as defined in the DT Parameters characteristic.

When the Server supports the Propose Non-Logged Time Adjustment Limit, the Non_Logged_Time_Adjustment_Limit_Old field reveals the old value before the change to the Non_Logged_Time_Adjustment_Limit. This field has the same format as the field as defined in the DT Parameters characteristic.

When the Server has made adjustments to the Base_Time within the Non_Logged_Time_Adjustment_Limit, the Non_Logged_Time_Adjustment_Counter field represents the number of consolidated non-logged time adjustments that the Server performed on the Base_Time that resulted in the accumulation of Base_Time adjustments, as revealed in the Active_Time_Adjustments field as described in Section 3.4.1.1.1.2.

When the Server consolidates Time Faults or Time Updates to a single entry, the Consolidated_Log_Counter field represents the number of consolidated log entries of the same Log Type as described in Section 3.4.1.1.1.1.

When the Server has made adjustments to the Base_Time value using either consolidation or non-logged time adjustments, the Active_Time_Adjustments field reveals the total of the adjustments. This structure is a group of fields that is used to both report and store Base_Time adjustments.

If the Server supports the Retrieve Active Time Adjustments feature, when either or both of the DT_Status bits for Non-Logged Time Change Active or Log Consolidation Active, when set to 1, reveals that this group of fields is available using the DTCP (see Section 3.7.1.2.1).

A Time_Change_Log_Data_Record field that contains the Active_Time_Adjustments field reveals that the Server made one or several Base_Time adjustments by either accumulated non-logged time adjustments or consolidated Base_Time adjustments or both.

The structure of the Active_Time_Adjustments field is shown in Table 3.13. The data fields that make up the Active_Time_Adjustments field are described in the following sub-sections.

The Displayed_Formats field reveals the new value from Table 3.5 after the change to the Displayed_Formats. The formatting of this field is as defined in the DT Parameters characteristic.

The Displayed_Formats_Old field reveals the value before the change to the Displayed_Formats. The formatting of this field is the same as that of the Displayed_Formats field defined in the DT Parameters characteristic.

When the DTCP characteristic is configured for indications, the Server shall respond to writes to this control point using the control point response; otherwise, the Server shall respond with an error for Client Characteristic Configuration Descriptor Improperly Configured [4].

When the RACP characteristic is configured for indications, and the Time Change Log Data characteristic is configured for notifications, the Server shall respond to writes to this control point using the control point response; otherwise, the Server shall respond with an error for Client Characteristic Configuration Descriptor Improperly Configured [4].

This section describes the operands for the Request Opcodes of the DTCP (see Table 3.15).

This section describes the Operands for the Response Opcodes available in DTCP (see Table 3.15).

This section contains Time Update behaviors that are common to both the Propose and Force update procedures.

This section describes expected Server behavior when responding to the DTCP Opcode for Propose Time Update under various system configurations.

The Server may compare the quality and accuracy of the fields within the operand of a Proposed Time Update with its own time quality values and accuracy values before accepting the proposed Time Update. The Server may reject a Time Update proposal based on this comparative quality analysis. See Section A.8 for a discussion of time quality evaluation. In general terms, the Server should reject a Time Update proposal that reduces the Server’s time quality and respond to the Client with the appropriate Rejection Flag(s) set in the operand of the DTCP Response_Value for Procedure Rejected (see Table 3.21).

A Server that receives a Propose Time Update procedure with an operand that contains a valid Base_Time_Update value may use the Response Rejection Flag for Base_Time_Update is unrealistic (bit 0 is set to 0 after determining that the Base_Time_Update value appears to be too far from the expected Base_Time value to be realistic). The Server’s rejection of the Base_Time_Update value may occur whether or not the Server has restricted the range of valid values for Base_Time and whether or not the rejected Base_Time_Update value is within the Server’s restricted range.

If the Server supports the Base Time Second-Fractions feature and the Second-Fractions Not Valid bit of the Propose Time_Update_Flags is set to 1, the Server may reject the Propose Time Update using the DTCP Response_Opcode with DTCP Response_Value for Procedure Rejected (0x05) with Rejection Flags indicating Lack of Precision (0x08) and/or Base_Time_Update rejected but local time values accepted (0x09).

The Server shall accept all Force Time Update procedures from an authorized Client without evaluation as to the comparable quality of the Client’s time values versus the Server’s time values.

When a Server supports the Base Time Second-Fractions feature, the Second-Fractions Not Valid bit of the Time_Update_Flags being set to 1 shall not be a reason for rejection of a Force Time Update procedure.

When the Server supports the Propose Non-Logged Time Adjustment Limit feature, the Server shall allow an authorized Client to initiate the DTCP procedure Propose Non-Logged Time Adjustment Limit. The Server may limit the values that an authorized Client may write to the Non-Logged Time Adjustment Limit field.

If the Server accepts the value from the Propose Non-Logged Time Adjustment procedure, and the Server supports the Time Change Logging feature, then the Server creates a time change log for this event and includes the fields as described in Table 3.10 for the DT_Parameters_Changed event (see Section 3.4.1.1.5).

The Server may reject the Propose Non-Logged Time Adjustment Limit procedure using the DTCP Response_Opcode with the Response_Value for Procedure Rejected, and the Server shall provide the appropriate Parameter Rejection Flag(s) per Table 3.22.

When the Server supports the Retrieve Active Time Adjustments feature, and the Server has made adjustments to the Base_Time due to log consolidations or non-logged time adjustments (see Sections 3.3.1.5.6 and 3.3.1.5.7), and the Server receives a Request_Opcode for Retrieve Active Time Adjustments, the Server shall respond with the Report Active Time Adjustment Response_Opcode using the operand as described in Table 3.19.

When the Server supports the Retrieve Active Time Adjustments feature, and the Server is not actively making unlogged-Base_Time adjustments reported by this procedure, and the Server receives a Request_Opcode for Retrieve Active Time Adjustments, the Server shall respond with the Response_Opcode for Report Active Time Adjustments with the operand described in Table 3.19 showing all the supported fields set to a value of zero as confirmation that no Base_Time adjustments are applied to the Base_Time value of the DT characteristic.

When a Server does not support the Retrieve Active Time Adjustments feature or when the Server cannot complete the procedure, the Server shall respond using the DTCP Response Code opcode with the appropriate failure Response_Value (see Table 3.21).

Because the value of the operand is defined per service, when the RACP is used with the Device Time Service, the Filter_Type parameter of the operand is defined exclusively as ‘Sequence Number’.

In DTS, some RACP procedures have operands that require multiple parameter values to support searching of response data. When required by an operator, the Filter_Type parameter octet shall precede the applicable Filter_Value parameter octets within the operand. For example, when used with the “within range of” operator, the operand has the transmission order of; <Filter_Type><minimum Filter_Value><maximum Filter_Value>, where the Filter_Type field value is the Least Significant Octet of the operand.

See Table 3.27 for the ‘Sequence Number’ Filter_Type enumeration.

When the Combined Report opcode is written to the RACP the Server shall notify the requested set of stored records based on the filter criteria specified in the operator and operand. Refer to Table 3.25 for operand requirements when used with a specific operator and note that in some cases, no operand is used. The semantics of a record transfer is a “copy” of the records and not a” move” of the records so that the Server retains the original log entries.

If, during the record transfer, a new history record becomes available (in other words, after the Combined Report procedure is initiated), the Server may include this new record in the history transfer.

Once all records for a given request have been notified by the Server, the Server shall indicate the RACP with the Response Opcode for Combined Report Response, operator of Null, and the operand equal to the number of records sent (see RACP in [3]).

If the Server does not locate any records matching the request, the Server shall indicate the RACP with a Combined Response, operator of Null, and the operand set to 0.

When the Server is reporting stored records, the Server shall report records by order of first in first out (FIFO, oldest Sequence Number first).

If the operation results in an error condition, this shall be indicated using the Response Code opcode, operator of Null, Request Opcode of Combined Report, and the appropriate Response Code Value in the operand for the error condition (see Sections 3.8.3.6 and 3.5.3).

If the Server ends its data transfer of requested records before completion for any reason other than the Abort Operation procedure (see Section 3.8.3.5), the Server shall indicate the RACP with the Response Code, operator of Null, Request opcode of Combined Report, and a Response Code Value in the operand set to Procedure Not Completed.

When the Report Stored Records opcode is written to the RACP, the Server shall notify the selected set of stored records based on the filter criteria specified in the operator and operand. Refer to Table 3.25 for operand requirements when used with a specific operator and note that in some cases, no operand is used. The semantics of a record transfer is a “copy” of the records and not a ”move” of the records so that the Server retains the original log entries.

If, during the record transfer, a new history record becomes available (in other words, after the Report Stored Records procedure is initiated), the Server may include this new record in the history transfer if the new record satisfies the filter criteria of the executing records request.

Once all data records for a given request have been notified by the Server, the Server shall indicate the RACP with the Response Code, operator of Null, a Request opcode of Report Stored Records, and a Response Code Value in the operand set to Success (see RACP in [3]).

If the Server does not locate any records matching the request, the Server shall indicate the RACP with the Response Code, operator of Null, Request opcode of Report Stored Records, and a Response Code Value in the operand set to No Records Found (0x06).

When the Server is reporting stored records, the Server shall report records in first in first out (FIFO) order.

If the operation results in an error condition, this shall be indicated using the Response Code, operator of Null, Request opcode of Report Stored Records, and the appropriate Response Code Value in the operand for the error condition (see Sections 3.8.3.6 and 3.5.3).

If the Server ends its data transfer of requested records before completion for any reason other than the Abort Operation procedure (see Section 3.8.3.5), the Server shall indicate the RACP with the Response Code opcode, operator of Null, Request Opcode of Report Stored Records, and a Response Code Value in the operand set to Procedure Not Completed.

When the Report Number of Stored Records opcode is written to the RACP, the Server shall calculate and respond with a record count based on the operator and operand values. See Table 3.25 for operand requirements when used with a specific operator and note that in some cases, no operand is used. The record count reported in the response is calculated based on the current state of the Server history record database and may change between connections as records are created or created and over-written. The response to the Report Number of Stored Records procedure is indicated using the Number of Stored Records Response.

If the Server does not locate any records matching the request, the Server shall indicate the RACP with the Number of Stored Records Response Opcode, the Null operator, and the operand set to a count of no records (0x0000).

If the operation results in an error condition, this shall be indicated using the Response Code and the appropriate Response Code Value in the operand for the error condition (see Sections 3.8.3.6 and 3.5.3).

When the Abort Operation opcode is written to the RACP, the Server shall stop any RACP procedures that are in progress and stop sending any further data.

Once all RACP procedures have been stopped, the Server shall indicate the RACP with the Response Code, operator of Null, Request Opcode of Abort Operation, and a Response Code Value in the operand set to Success.

If the operation results in an error condition, this shall be indicated using the Response Code, operator of Null, Request Opcode of Abort Operation, and the appropriate Response Code Value in the operand for the error condition (see Sections 3.8.3.6 and 3.5.3).

If the Filter_Type parameter value within an operand that was written to the RACP is an RFU value, the Server shall indicate the RACP with the Response Code, operator of Null, the appropriate Request Opcode, and a Response Code Value in the operand set to Operand Not Supported (see Record Access Control Point in [3]).

If the Server is unable to process the Abort Operation procedure for any reason not stated in this Section, the Server shall indicate the RACP with the Response Code, operator of Null, the appropriate Request Opcode, and a Response Code Value in the operand set to Abort Unsuccessful.

If the operator that was written to the RACP is not supported by the Server (see Table 3.25), then the Server shall indicate the RACP with the Response Code, operator of Null, the appropriate Request Opcode, and a Response Code Value in the operand set to Operator Not Supported.

If the operator that was written to the RACP is supported by the Server but is not applicable for the used opcode, the Server shall indicate the RACP with the Response Code, operator of Null, the appropriate Request Opcode, and a Response Code Value in the operand set to Invalid Operator.

If a request with an opcode other than Abort Operation is written to the RACP while the Server is performing a previously triggered RACP operation (in other words, resulting from invalid Client behavior), the Server shall return an error response with the Common Profile and Service error code of Procedure Already In Progress (see [3]).