DDS Interoperability Wire Protocol Avatar
  1. OMG Specification

DDS Interoperability Wire Protocol — All Issues

  • Acronym: DDSI-RTPS
  • Issues Count: 20
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
DDSIRTP26-3 SequenceNumberSet validity could be too strict DDSI-RTPS 2.3 open
DDSIRTP25-34 Change the CRC-64 polynomial introduced in issue DDSIRTP25-12 DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-4 Unclear specification on how the Publisher GUID is communicated DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Duplicate or Merged closed
DDSIRTP25-3 Incomplete specification of how a Publisher and Subscriber are identified DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-2 Discriminating the reasons for a GAP DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-12 Address deferred issue: Inclusion of Message Size & CRC as part of DDSI/RTPS Messages DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-17 Editorial corrections DDSI-RTPS 2.3 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-25 Revise list of Submessages EntityIDs and PIDs reserved for other specifications DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-28 Apply modifications to Clause 9.6.3.8, “KeyHash (PID_KEY_HASH)" from XTYPES DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-9 Flag GroupInfoFlag and fields gapStartGSN and gapEndGSN unspecified in PSM DDSI-RTPS 2.3 DDSI-RTPS 2.5 Duplicate or Merged closed
DDSIRTP25-1 SEQUENCENUMBER_UNKNOWN missing from PSM DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-27 Support transport-level RTPS message compression DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Deferred closed
DDSIRTP25-24 Add an INFO_AGE submessage DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Duplicate or Merged closed
DDSIRTP25-6 Update Acknowledgemts, Copyright and Statement of Proof DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-11 currentGSN.value < lastGSN.value condition seems wrong DDSI-RTPS 2.3 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-10 8.3.7.5 / 9.4.5.6 HeartBeat Submessage DDSI-RTPS 2.3 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-7 PSM and PIM description of Gap message not matching DDSI-RTPS 2.3 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-13 Interoperability of Transient/Persistent data DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Deferred closed
DDSIRTP26-2 Support transport-level RTPS message compression DDSI-RTPS 2.3b1 open
DDSIRTP26-1 Interoperability of Transient/Persistent data DDSI-RTPS 2.3b1 open

Issues Descriptions

SequenceNumberSet validity could be too strict

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    9.4.2.6 SequenceNumberSet defines one of the rules for validity as
    bitmapBase >= 1

    We have observed that other implementations use bitmapBase 0 in AckNack submessages. There seems to be no downside to just accepting these as valid even though the spec currently says they are not.

    The RTF should determine if this condition in 9.4.2.6 can just be removed.

  • Reported: DDSI-RTPS 2.3 — Mon, 7 Jun 2021 22:55 GMT
  • Updated: Tue, 30 May 2023 22:53 GMT

Change the CRC-64 polynomial introduced in issue DDSIRTP25-12

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The CRC-64 polynomial selected in DDSIRTP25-12 (a.k.a. CRC-64-iso) has issues that make it inadequate for this specification:

    • The "only" formal reference is ISO 3309 which has been "withdrawn". The ISO 3309 page (https://www.iso.org/standard/8561.html) says it has been revised by ISO/IEC 13239:2002. However ISO/IEC 13239 does not mention CRC 64 at all. Moreover the later versions of the (withdrawn) ISO 3309, for example ISO-IEC-3309:1993 only mention CRC-32 polynomials, no CRC-64 polynomials.
    • It seems to have fallen out of use: The two references that Wikipedia says use this polynomial (Swiss-Prot/TrEMBL) and HDCL seems to no longer use the CRC64-ISO polynomial:
      1. Swiss-Prot/TrEMBL has changed to a different CRC-64 polynomial (see https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.368.2736&rep=rep1&type=pdf).

    2. HDLC is defined in the ISO/IEC 13239 and it does not define CRC 64 bit polynomials.

    Because of this the polynomial should be changes to the so called CRC-64-ECMA which as a specification that is not deprecated https://www.ecma-international.org/publications/standards/Ecma-182.htm. This polynomial is used in other relates specifications such as AUTOSAR: AUTOSAR 4.3 added CRC-64 with the ECMA polynomial (https://www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_SWS_CRCLibrary.pdf).

    Moreover specifying the polynomial coefficients is not enough to fully specify the checksum. Instead there are additional rules about padding etc. For this reason the specification should be amended to include all the additional information.

  • Reported: DDSI-RTPS 2.3b1 — Tue, 9 Feb 2021 13:38 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Replace the CRC-64 polynomial with the CRC-64/XZ checksum polynomial

    Amend the resolution of DDSIRTP25-12 replacing the CRC-64 checksum polynomial and description with one that used the so called CRC-64/XZ checksum as utilized in AUTOSAR Classic Platform release R20-11, Specification of CRC Routines.

    Expand the description of the CRC-32 and CRC-64 algorithms to define all the parameters needed to uniquely compute and validate the checksum, including the polynomial coefficients, whether the input data and output data are reflected, the initial value and the final XOR value.

  • Updated: Tue, 29 Jun 2021 12:54 GMT

Unclear specification on how the Publisher GUID is communicated

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification uses a field called remoteGroupEntityId (see Table 8.67) to identify Publishers and Subscribers.

    Furthermore it specifies that this s communicated using a PID_ENDPOINT_GUID.

    It seems that this is related to PID_GROUP_GUID.
    But Table 9.14 says that PID_GROUP_GUID is "reserved for future versions"

    The relationship between this should be clarified.
    Furthermore the implementation of GROUP order and coherent access (8.7.5 and 8.7.6) require knowledge of which DataWriter belong to which Publishers. But how this is discovered is not specified.

    Minimally we should say that:

    A Publisher has a GUID that should be constructed from the GuidPrefix_t and an Entity_id.

    The PublisherGUID shall be communicated vis discovery using either a PID_GROUP_ENTITYID or PID_GROUP_GUID

    The WriterProxy::remoteGroupEntityId should contain the Publisher GUID

  • Reported: DDSI-RTPS 2.3b1 — Sat, 2 Mar 2019 19:57 GMT
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.5
  • Disposition Summary:

    Duplicates DDSIRTP25-3

    Duplicates DDSIRTP25-3

  • Updated: Tue, 29 Jun 2021 12:54 GMT

Incomplete specification of how a Publisher and Subscriber are identified

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification uses a field called remoteGroupEntityId (see Table 8.67) to identify Publishers and Subscribers.

    Furthermore it specifies that this s communicated using a PID_ENDPOINT_GUID.

    It seems that this is related to PID_GROUP_GUID.
    But Table 9.14 says that PID_GROUP_GUID is "reserved for future versions"

    The relationship between this should be clarified.
    Furthermore the implementation of GROUP order and coherent access (8.7.5 and 8.7.6) require knowledge of which DataWriter belong to which Publishers. But how this is discovered is not specified.

    Minimally we should say that:

    A Publisher has a GUID that should be constructed from the GuidPrefix_t and an Entity_id.

    The PublisherGUID shall be communicated vis discovery using either a PID_GROUP_ENTITYID or PID_GROUP_GUID

    The WriterProxy::remoteGroupEntityId should contain the Publisher GUID

  • Reported: DDSI-RTPS 2.3b1 — Sat, 2 Mar 2019 19:56 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Add information on the identification of Publisher and Subscriber

    Indicate that the Publisher and Subscriber are identified by a GUID and that the GUID is propagated via the Publication and Subscription builtin Topic data.

  • Updated: Tue, 29 Jun 2021 12:54 GMT
  • Attachments:

Discriminating the reasons for a GAP

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The GAP message indicates a gap in sequence numbers that is "not available" to the DataReader. It may be caused by filters (time, content), history keep last, or lifespan.

    In some cases the reason behind the gap is important to the receiving application. For example a missing sequence number caused by a writer-side content filter does not invalidate a coherent change. However if the gap is caused by keep-last history the coherent change must be discarded by the subscriber/reader.

    Currently there is no way for the receiving application to tell the difference.

    There may be also other situations where it may be desirable to account for the different reasons that cause a gap. For example if the reader maintains a "sample lost count" it needs some way to distinguish sample loss from things it it chose to not receive.

    The RTF should address this issue and provide the means to discriminate these cases. A possible approach would be include the information in the flags of the GAP message.

  • Reported: DDSI-RTPS 2.3b1 — Thu, 28 Feb 2019 02:41 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Extend GAP submesage to provide information about the reasons for the samples gapped

    Extend the GAP message with optional counters to indicate the numbers of samples that are gapped that fall into one of 3 categories:

    • Non-relevant Samples
    • Relevant Samples
    • Unclassified Samples

    Non-relevant samples are those that are intentionally not sent to the DataReader because they do not match some reader-specified criteria. These include samples filtered dues to a content-filtered topic, samples filtered due to a time-based filter, samples directed to other data readers, etc.
    Non-relevant samples are not considered “lost” and do not invalidate coherent changes.

    Relevant samples are those that should have been received by the DataReader but are not received due to various reasons. They include samples that are lost by the transport when using BEST_EFFORT datawriters, samples replaced in the DataWriter cache due to a HISTORY kind KEEP_LAST, samples removed from the DataWriter cache due to LIFESPAN, etc.
    Relevant samples are considered “lost”. They are counted as such and invalidate coherent changes.

    Unclassified samples are those that are not accounted for by the above two categories. This may be because the DataWriter cannot determine or does not keep track of the reason some sequence numbers are missing for a DataReader.
    Unclassified samples are treated the same way we treat the samples missing dues to GAPs or HEARTBEATs in previous versions of the specification. That way the behavior is backwards compatible.

    The updated GAP message would should like this:

    0...2...........7...............15.............23...............31
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   GAP      	|X|X|X|X|N|R|G|E| 	octetsToNextHeader      |
    +---------------+---------------+---------------+---------------+
    |        EntityId          	readerId                        |
    +---------------+---------------+---------------+---------------+
    |        EntityId          	writerId                        |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    +        SequenceNumber    	gapStart                        +
    |                                                               |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    ~        SequenceNumberSet	gapList                         ~
    |                                                               |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    +        SequenceNumber    	gapStartGSN  [ only if G==1 ]   +
    |                                                               |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    ~        SequenceNumber    	gapEndGSN    [ only if G==1 ]   ~
    |                                                               |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    +        ChangeCount             relevantCount      [if R==1]   +
    |                                                               |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    +        ChangeCount             nonRelevantCount   [if N==1]   +
    |                                                               |
    +---------------+---------------+---------------+---------------+
    

    Where the 'R' and 'N' are new flags and the added SequenceNumberCount sub-message elements are 64 bit counter encoded the same way as a sequence number:

    +---------------+---------------+---------------+---------------+
    |                      int32      low                           |
    +   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   +
    |                      int32      high                          |
    +---------------+---------------+---------------+---------------+
    

    If R==0, relevantCount shall be set to zero.
    If N==0, nonRelevantCont shall be set to zero.

    The number or unclassified samples shall be set by the formula:

    
    unclassifiedCount  = (gapList.bitmapBase - gapStart) + gapList.numBits
                      -(relevantCount + nonRelevantCount)
    

    In other words, any samples that appear as part of the GAP but are not covered by the relevant count and the irrelevant count.

  • Updated: Tue, 29 Jun 2021 12:54 GMT
  • Attachments:

Address deferred issue: Inclusion of Message Size & CRC as part of DDSI/RTPS Messages

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The following issue https://issues.omg.org/browse/DDSIRTP23-6 was deferred in the last RTF so it should have been moved to this RTF. Since it didn't happen automatically we are entering this issue manually here.

    For details on the previous discussion and what was proposed as a resolution see DDSIRTP23-6.

    Overall Approach
    -----------------------
    Introduce a new RTPS submessage "RTPSHeaderExtension" with the following elements:

    • messageLength

    The messageLength indicates the length of the RTPS message
    The rtpsSendTimestamp indicates the time when the message was sent
    The messageChecksum

    Mechanisms to add additional information in future revisions.

    The RTPSHeaderExtension submessage, if present, shall follow immediately after the RTPS Header

    The DDS Security specification will leave this RTPSHeaderExtension following the RTPS Header and before the SecureRTPSPrefixSubMsg. The length will be updated to the new length after processing by the security plugins.

  • Reported: DDSI-RTPS 2.3b1 — Fri, 20 Mar 2020 20:07 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Add CRC support via a HeaderExtension submessage

    Introduce a new RTPS submessage "RTPSHeaderExtension" with the following elements:

    • rtpsMsgLength (indicates the length of the RTPS message)
    • rtpsPort (destination port for submessage)
    • rtpsChecksum (message checksum)

    The RTPSHeaderExtension submessage, if present, shall follow immediately after the RTPS Header.

  • Updated: Tue, 29 Jun 2021 12:54 GMT
  • Attachments:

Editorial corrections

  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    7.6 enumerated list 5th bullet

    • The transport will drop m essages if incomplete or corrupted during transfer

    -> messages



    8.2.4

    Table 8.6 - RTPS Entity Attribues

    -> Attributes



    8.2.6

    Table 8.9 - RTPS Endpoint configuration attribues

    -> attributes



    8.3.7.2.5 'Logical Interpretation' enumerated list 1st bullet (8.3.8.2.5 after revisions to the spec)

    • If the DataFlag [...], the serializedPayload element is interpreted as
      the value of the dtat- object.

    -> data-object



    8.3.7.9.2 'Content' (8.3.8.10.2 after revisions) Table 8.42 (8.48 after revisions) 2nd row 3rd column (meaning)

    Indicates the protocol used for subsequent Sudmessages.

    -> Submessages



    8.4.2.3.2 'Readers must respond eventually after receiving a HEARTBEAT that indicates a sample is missing' 1st para 2nd sentence

    This requirement only applies if the Reader
    can accomodate these missing samples in its cache [...]

    -> accommodate



    Replace "bandwith" with "bandwidth" in section 8.4.2, and 8.7.2.2.4 (2 times total).



    8.6.2 enumerated list 3rd bullet

    * The meaning of submessageIds cannot be modfied.

    -> modified



    8.7.2.2.4 1st sentence

    Implementations may optimize bandwith usage by applying a time-based filter on the Writer side.

    -> bandwidth



    8.7.4 4th para 1st sentence

    When RTPS sends a Data Submessge to communicate instance state changes it may include only the Key of

    -> Submessage



    8.7.4 6th para numbered list

    1. If the previous update to the instance passed the filter, [...]
    that either includes the data value, or else indicates the IntanceState is ALIVE_FILTERED.

    -> InstanceState



    8.7.9 3rd para

    The RTPS protocol suports this forwarding of messages by including information of the original writer.

    -> supports



    9.1 enumerated list 4th bullet

    • [...]; this allows multiple RTPS endpoints to
      share a single operat- ing-system UDP resource (socket/port) while

    -> operating system



    9.3.1.2 Mapping of the EntityId_t

    typedef octet OctetArray3[3]; struct {
    OctetArray3 entityKey; octet entityKind;
    };
    

    -->

    typedef octet OctetArray3[3]; 
    struct EntityId_t {
        OctetArray3 entityKey; 
        octet entityKind;
    };
    



    9.4.5.7.1 Flags in the Submessage Header

    Reference to (8.3.6.2).

    -> 8.3.8.6.2



    9.4.5.15.1

    The MulticastFlag is [...]. M=1 means the InfoReplyIp4 also includes a
    multicastRLocator.

    -> multicastLocator



    9.6.2.3 1st sentence

    The port number expresssions use the following parameters:

    -> expressions



    9.6.4.9, 7th para

    The DisposeedFlag is represented with the literal 'D.'

    -> DisposedFlag

  • Reported: DDSI-RTPS 2.3 — Tue, 21 Apr 2020 08:05 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Apply the typo corrections specified in the issue description

    Perform the suggested corrections.

  • Updated: Tue, 29 Jun 2021 12:54 GMT

Revise list of Submessages EntityIDs and PIDs reserved for other specifications

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    It seems that some ranges reserved by other specifications (e.g. XTypes type service) are missing from RTPS. They should be added:

    9.4.5.1.1.1 for SubmessageIDs
    to 9.3.1.3.1 for the EntityIDs
    Table 9.12 for ParameterIDs

    Maybe always list the same set of specs: DDS Security, XTypes, DDS-RPC? and indicate explicitly if a specification does not reserve anything.

    Also figure out whether new builtin endooints show up under the "availableBuiltinEndpoints" see Table 8.73 also the IDL in 9.3.2
    Right now there is a comment in the IDL that says:

    /* Bits 12-15 have been reserved by the DDS-Xtypes 1.2 Specification
    and future revisions thereof.
    Bits 16-27 have been reserved by the DDS-Security 1.1 Specification
    and future revisions thereof.
    */

    Maybe this needs ti be more explicit and get its own section.

  • Reported: DDSI-RTPS 2.3b1 — Wed, 24 Jun 2020 19:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Be more explicit about submessageID, PatameterIDs and EndpointIDs reserved by other DDS specifications

    Create a new subsection to describe the reserved bits in the availableBuiltinEndpoints.

    Add information to section 9.3.1.3.1 'EntityIds Reserved by other Specifications' to include the endpoints reserved by XTYPES

    Add a new subsection under 9.3.2 'Mapping of the Types that Appear Within Submessages or Built-in Topic Data' to fully describe the content of the 9.3.2.12 BuiltinEndpointSet_t

    Create new subsection before 9.6.5 'ParameterIds Deprecated by the Protocol' to define parameter IDs reserved by other specifications.

  • Updated: Tue, 29 Jun 2021 12:54 GMT

Apply modifications to Clause 9.6.3.8, “KeyHash (PID_KEY_HASH)" from XTYPES

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    XTYPE 1.3, section 7.6.8 "Interoperability of Keyed Topics" provided amended text for Clause 9.6.3.8 in the RTPS spec. This text should be applied to the RTPS spec.

  • Reported: DDSI-RTPS 2.3b1 — Tue, 8 Dec 2020 15:52 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Replace the text in 9.6.4.8 'KeyHash (PID_KEY_HASH)'

    Replace the text in 9.6.4.8 KeyHash (PID_KEY_HASH) with the one provides in DDS-XTYPES 1.3, section 7.6.8 "Interoperability of Keyed Topics" p

  • Updated: Tue, 29 Jun 2021 12:54 GMT

Flag GroupInfoFlag and fields gapStartGSN and gapEndGSN unspecified in PSM

  • Status: closed  
  • Source: N/A ( Frans Schneider)
  • Summary:

    In the message module, the submessage gap defines the flag GroupInfoFlag and the fields gapStartGSN and gapEndGSN. However, in the PSM, both this flag and the two fileds are not specified further.

  • Reported: DDSI-RTPS 2.3 — Fri, 7 Feb 2020 12:28 GMT
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.5
  • Disposition Summary:

    Duplicates DDSIRTP25-7

    Merged with DDSIRTP25-7

  • Updated: Tue, 29 Jun 2021 12:54 GMT

SEQUENCENUMBER_UNKNOWN missing from PSM

  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The previous version of the spec (formal/14-09-01) contained the following in Table 9.4
    #define SEQUENCENUMBER_UNKNOWN {-1, 0}
    However, the equivalent definition is missing in the 2018 "Beta" spec.

  • Reported: DDSI-RTPS 2.3b1 — Tue, 22 Jan 2019 18:12 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Add SEQUENCENUMBER_UNKNOWN

    Add specification for SEQUENCENUMBER_UNKNOWN with definition matching previous versions of the protocol (high = -1, low = 0)

  • Updated: Tue, 29 Jun 2021 12:54 GMT

Support transport-level RTPS message compression

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Some transports have limited bandwidth and may benefit from compressing the RTPS message prior to being sent over the transport.

    This is something that could be added in a reasonably simple manner by considering this part of the transport PSM.

  • Reported: DDSI-RTPS 2.3b1 — Mon, 14 Sep 2020 15:06 GMT
  • Disposition: Deferred — DDSI-RTPS 2.5
  • Disposition Summary:

    Defer to the next RTF.

    Defer to the next RTF.

  • Updated: Tue, 29 Jun 2021 12:54 GMT

Add an INFO_AGE submessage

  • Status: closed  
  • Source: Kongsberg Defence & Aerospace ( Dr. Ornulf Staff)
  • Summary:

    The INFO_AGE submessage is semantically similar to INFO_TS, but it contains a Duration_t instead of a Time_t. It assigns a time to subsequent submessages that the service may use for functionality like lifespan and sample ordering.

    Transmitting a sample age gives the receiver an inexact timestamp. There will be an unknown time span between the time the sender calculates the age and the time the receiver transforms it back to a local time. If the receiver does no adjustment based on estimated latency, the calculated time will always be too high. However, the error will in practice be bounded and in many scenarios the receiver will have a time that is within one second of the actual sample time.

    Kongsberg uses a submessage like this today for deployments where no correct time source is available. This might be because the system has to be fully operational before a good time source is ready, or because some systems have requirements that mandate that the system clock must be adjustable. We have found that this is a better solution than attempting to have some form of synchronized "DDS time" on the network, because coming up with a network time that works very quickly at startup and is robust to network fragmentation is challenging.

    The use of the INFO_AGE message is enabled by a vendor specific configuration option to the participant containing the publisher. It may either be sent as an alternative to INFO_TS or in combination with INFO_TS to allow the subscriber to determine which time to use an also for compatibility with systems without support for INFO_AGE.

    INFO_AGE allows two features on systems with no time synchronization:

    • Full support for sample lifespan QoS, as long as lifespan is an order of magnitude larger than network latency
    • Partial support for by source timestamp QoS. It may be used to determine that some samples are clearly older than others, in practical use when the time difference is on the order of seconds. When estimated times are within the uncertainty margin, the subscriber needs to treat them as by destination order QoS to avoid surprising behavior when e.g. a writer publishes several samples in quick succession.

    It should be noted that a system based on INFO_AGE with multiple readers and writers on the same topic will have a non-deterministic sample order on the readers.

  • Reported: DDSI-RTPS 2.3b1 — Mon, 22 Jun 2020 12:27 GMT
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.5
  • Disposition Summary:

    Merge with DDSIRTP25-12

    This can be merged with DDSIRTP25-12

  • Updated: Tue, 29 Jun 2021 12:54 GMT

Update Acknowledgemts, Copyright and Statement of Proof

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 6.3 'Acknowledgments' lists the companies that contributed to the spec. This list needs to be updated to include the companies that contributed to the latests revisions (e.g. as members of the RTF task forces). This includes TwinOaks, Kongsberg, OCI, ADLink, MITRE, NSWC, etc.

    We may also want to list contributor's names as we do for other specs.

    Section 6.4 'Statement of Proof ...' needs to be updated this text has been carried from the original version. Something much stronger can be said today.

    Copyright should be updated to include the companies in the 'Acknowledgments'

  • Reported: DDSI-RTPS 2.3b1 — Tue, 24 Sep 2019 21:23 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Update section 6.3 'Acknowlegments' an copyrights

    As stated in the issue description update the acknowledgments and copyright to include people that participated in the various RTFs

  • Updated: Tue, 29 Jun 2021 12:54 GMT

currentGSN.value < lastGSN.value condition seems wrong

  • Status: closed  
  • Source: N/A ( Frans Schneider)
  • Summary:

    The last condition seems wrong. Shouldn't that be greater than instead of less than?
    If GroupInfoFlag is set and:
    • currentGSN.value is zero or negative
    • firstGSN.value is zero or negative
    • lastGSN.value is negative
    • lastGSN.value < firstGSN.value - 1
    • currentGSN.value < firstGSN.value
    • currentGSN.value < lastGSN.value

  • Reported: DDSI-RTPS 2.3 — Mon, 10 Feb 2020 08:26 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    *Correct section 8.3.7.6.3 'Validity' (Hearbeat) *

    I section 8.3.7.6.3 'Validity' (Hearbeat). Change:
    currentGSN.value < lastGSN.value
    to
    currentGSN.value > lastGSN.value

  • Updated: Tue, 29 Jun 2021 12:54 GMT

8.3.7.5 / 9.4.5.6 HeartBeat Submessage

  • Status: closed  
  • Source: N/A ( Frans Schneider)
  • Summary:

    In the message module, the submessage heartbeat defines the flag GroupInfoFlag and the fields currentGSN, firstGSN, lastGSN. writerSet and secureWriterSet. A specification for this flag and the fileds is missing in the PSM.

  • Reported: DDSI-RTPS 2.3 — Fri, 7 Feb 2020 13:20 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Add information on the GroupInfoFlag to 9.4.5.7 'HeartBeat Submessage'

    Add missing information on the GroupInfoFlag and elements currentGSN , firstGSN, and lastGSN to section 9.4.5.7 'HeartBeat Submessage'

  • Updated: Tue, 29 Jun 2021 12:54 GMT

PSM and PIM description of Gap message not matching

  • Status: closed  
  • Source: S2E Systems ( Joao Rebelo)
  • Summary:

    The wire representation of the GAP message given in 9.4.5.5. does not match the logical PIM description given in the sub-clause 8.3.7.4 in the following points:

    • Section 9.4.5.5.1 mentions that "This Submessage has no flags in addition to the EndiannessFlag". Section 8.3.7.4.2 describes "GroupInfoFlag" with the following text "Appears in the Submessage header flags"
    • "gapStartGSN" and "gapEndGSN" sequence numbers do not appear in the wire representation
  • Reported: DDSI-RTPS 2.3 — Mon, 11 Nov 2019 20:45 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Add GapInfoFlag information to section 9.4.5.6 'Gap Submessage'

    Add information about the GapInfoFlag, gapStartGSN and gapEndGSN to section 9.4.5.6 'Gap Submessage'.

  • Updated: Tue, 29 Jun 2021 12:54 GMT

Interoperability of Transient/Persistent data

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The following issue https://issues.omg.org/browse/DDSIRTP23-26 was deferred in the last RTF so it should have been moved to this RTF. Since it didn't happen automatically we are entering this issue manually here.

  • Reported: DDSI-RTPS 2.3b1 — Fri, 20 Mar 2020 20:09 GMT
  • Disposition: Deferred — DDSI-RTPS 2.5
  • Disposition Summary:

    Defer to the next RTF. Until DDS 1.5 is adopted.

    The resolution of this issue depends on some decisions that need to be made on the DDS specification. These issues have been filed against the DDS also modifications to the DDS15 RTF which is still ongoing.

    Therefore the resolution of this issue is deferred to the next DDSI-RTPS RTF, which will be able to take into consideration the result of the DDS15 RTF.

  • Updated: Tue, 29 Jun 2021 12:54 GMT

Support transport-level RTPS message compression

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Some transports have limited bandwidth and may benefit from compressing the RTPS message prior to being sent over the transport.

    This is something that could be added in a reasonably simple manner by considering this part of the transport PSM.

  • Reported: DDSI-RTPS 2.3b1 — Mon, 14 Sep 2020 15:06 GMT
  • Updated: Fri, 9 Apr 2021 12:28 GMT