defines the structure of Remote Party Messages containing DLMS COSEM, ASN.1 and GBZ Payloads. A GBZ Payload is a Payload containing one or more ZSE messages;
defines the structure of Messages between a PPMID and a GSME on the same SMHAN; and
lays out specific requirements for DLMS COSEM and ZSE compliance to which Devices shall adhere.
Note that Remote Party Messages all use an aggregation structure which allows for multiple, protocol-specific instructions within the same Message. The aggregation structures are used for all Messages, are based on xDLMS access service, general signing service and general ciphering service formats, and provide protections across all types of Message payload (be they DLMS COSEM, ZSE or security related).
The GBCS does not provide more granular Message structures (e.g. for DLMS COSEM, individual set, get or action messages).
SMETS and CHTS require that the Critical Commands mandated by them (and so those defined in the GBCS) are the only Critical commands allowed. Devices may implement additional non Critical features only.
any action that the Known Remote Party takes to remedy a failure will need to factor in that some of the instructions succeeded and others did not;
in ASN.1 notation, the signature field in the general-signing service is a variable length OCTET STRING. When encoded, this means that the length of the signature needs to be incorporated before the actual signature value. The length is either 64 (0x40) if a signature is present or 0 (0x00) if signature is not present;
these requirements are to ensure that all Devices behave consistently and in the way required by originating Remote Party requests, including in error states; and
the WAN Provider may read CHF Operational Data and CHF Configuration Data, with their CHTS meanings, using mechanisms other than those defined in this GBCS.