1345   Fixed-length GOOSE ASN.1 length encoding

Created: 20 Jan 2015

Status: In Force (green)

Part: Part 8-1 (2011; Edition 2)

Links:

Page: 139

Clause: A.3

Paragraph:

Category: Issue may impact interoperability of implementations of Edition 2

Issue

A GOOSE Subscriber cannot predict the encoding of a fixed-length GOOSE message without knowing the Publisher's procedure for encoding the ASN.1 length octets. For example, a data length of 127 could be encoded in ASN.1 as:
7f
81 7f
82 00 7f

This may make it more difficult for some GOOSE Subscribers to decode the fixed-length GOOSE.

Proposal

There should be a specific rule about how the Publisher must encode the ASN.1 length octets, so that Subscribers know exactly what to expect. One of the following rules should be selected:

1. The Publisher must always encode the fewest possible ASN.1 length octets.
2. Since GOOSE message lengths cannot exceed 65535, the Publisher must always encode exactly three ASN.1 length octets, like this:
82 XX XX
3. For data lengths up to 127, the Publisher must encode exactly one ASN.1 length octet. Otherwise, it must encode exactly three ASN.1 length octets.

Discussion Created Status
The SOLUTION is: GOOSE publisher shall always use the minimum size BER encoding possible for length fields. 28 Jun 18 In Force (green)
This was discussed at the Regina Meeting and never got taken off hold. It should have been updated then.

The FINAL PROPOSAL is: GOOSE publisher shall always use the minimum size BER encoding possible for length fields. 		12 Apr 18 Ballot Period
Per WG10 meeting in Regina, GOOSE publisher must always use the minimum size BER encoding possible for length fields. 09 Jun 15 Future Improvement
30 Mar 15 Future Improvement
Efficient use of FIXED GOOSE requires that the position of data in allData can be determined from SCD file and NOT from "the first GOOSE message received". Recommend to change goID and simulation and ndsCOm to mandatory in fIXED GOOSE. The length field for the allData and IECGoosePdu elements shall each be encoded as 3 octets (82 XX XX). The length field for all other BER encodings shall be the minimum nuber of octets required to encode the <Value>. The result of these rules alow GOOSE subscriber to pre-compute data positions using only information contained in the SCD file.

This aligns with email discussions except for the goID element where this proposal uses 1 or 2 whereas email suggests "always (81 XX)". 		27 Mar 15 Ballot Period
20 Mar 15 Ballot Period
final Proposal:
IECGoosePdu length and allData length follow the BER encoding rule.
The encoding of the length of fields in the header where the length is not specified in the table A.1 (goCBRef, goID, datSet) shall be BER encoded. 		20 Mar 15 Ballot Period
What is the real issue is the encoding of the length of fields in the header where the length is not specified in the table. It is suggested that for Table A.1, where attribute lengths are not specified, BER encoding shall be used. 20 Mar 15 Discussion (red)
Table A.2 defines the length to be used for the basic data types.
VisibleString (not likely in a GOOSE) is fixed 20 bytes, OCTET STRING to 35 bytes. The length of the allData element is therefore fixed.
As is therewith the length for GOOSE wrapper.
Still, a subscriber must decode a message first, to verify the message information, the proper fixed encoding of the message and to determine therewith the offset to use; as datSet, and goID do not have a fixed length per definition, but a fixed length per configuration.
The subsriber has to ensure that the confRev is correct.
Therefore, there should not be an interop issue, as the offset must be verified before being applied.
09 Mar 15 Discussion (red)
I don't think that the "3-octet length" can be reserved only for the GOOSE wrapper and the allData.

There could be a structure encoded in the data that requires the "3-octet length" encoding. Also a VisString255 attribute (not likely in a GOOSE) could require it.

Any new rule would have to work for all possible GOOSE messages. 		27 Jan 15 Discussion (red)
BER does not enforce encoding the length field in the minimum number of octets.

Recoomend option 2 (3-octet length) for both the GOOSE wrapper and for the allData encoding. All other lengths for data inside allData shall be encoded using the single-octet length field.

This results in a maximum of 4 additional octets overhead for the GOOSE message 		20 Jan 15 Discussion (red)
Annex A.3 indicates this:

The Fixed-Length property for GOOSE is however backward compatible, as long as the subscriber implementation does not check if the shortest-length strategy has been respected in the BER encoding of the telegram.

Solution 2 is the expected and optimal solution. 		20 Jan 15 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.8.4.2